dimapas
Но с другой стороны , SQL-сервер , по моим наблюдениям , ещё стрёмнее. Доступ к нему на запись вообще с любой точки сети может быть осуществлён , включая WEB. C любой учёткой и любого пользователя , использующего любую прогу , которая к нему коннектится. А в больших организациях счёт таких учёток и раб. мест идёт на сотни.

Это как?

ssa

dimapas
А в больших организациях счёт таких учёток и раб. мест идёт на сотни.

Да что вы говорите?!
Вы где такой чуши набрались?

Вы не везде работали и не можете знать , как и где организована безопасность.
Есть госконторы , где Вы сможете увидеть своими глазами ещё и не такую "чушь". Администрирование там будет плохое , наслоение разношёрстных задач и сотрудников - мама не горюй. Контроль слабый и больше "для галочки"
И сделать с данными на SQL сервере там можно будет что угодно , с любой точки сети. При желании. И при отсутствии страха.

Так что ещё неизвестно , что там будет безопаснее , локальная база DBF или "общедоступный" сервер SQL у сисадмина "за пазухой".



Исправлено 5 раз(а). Последнее : dimapas, 14.03.18 14:11

dimapas
Мне нужно определиться с размером оплаты , сроками и целесообразностью этого занятия для себя.

Вот именно, "целесообразностью этого занятия для себя".
Насколько я понял ты порядка 20 лет не занимался фоксом. И оно тебе надо? Худо бедно конечно решишь задачу.
Ну, а дальше? Куда девать полученные знания за этот период?
Ну и, как говорится, ремонт нельзя закончить, его можно только остановить.
Все-равно в программе останутся слабые места. Ни дай бог новая версия понравится, то все, ты прилип. ;)
Посвящать сейчас свою жизнь изучению фокса - не самое лучшее занятие.

И конечно 8 месяцев. Народ будет крайне озабочен и нервозен. Такую задачу надо делать аврально.
Упал - отжался, выдохнул. Проект сдал - закурил и выпил шампанского.
Так или иначе нужно погрязнуть в существующем проекте. А ежели у тебя есть и текущие заботы/работы, то это крайне затруднительно.

dimapas

ssa

dimapas
А в больших организациях счёт таких учёток и раб. мест идёт на сотни.

Да что вы говорите?!
Вы где такой чуши набрались?

Вы не везде работали и не можете знать , как и где организована безопасность.
Есть госконторы , где Вы сможете увидеть своими глазами ещё и не такую "чушь".
И сделать с данными на SQL сервере что угодно , с любой точки сети. При желании. И при отсутствии страха.

Батенька, давайте вы нам не будете рассказывать сказки про обеспечение безопасности данных в сетях и об отношению к этому sql server'а. Ибо вы или бредите, или полный профан в этом вопросе.

ssa

dimapas

ssa

dimapas
А в больших организациях счёт таких учёток и раб. мест идёт на сотни.

Да что вы говорите?!
Вы где такой чуши набрались?

Вы не везде работали и не можете знать , как и где организована безопасность.
Есть госконторы , где Вы сможете увидеть своими глазами ещё и не такую "чушь".
И сделать с данными на SQL сервере что угодно , с любой точки сети. При желании. И при отсутствии страха.

Батенька, давайте вы нам не будете рассказывать сказки про обеспечение безопасности данных в сетях и об отношению к этому sql server'а. Ибо вы или бредите, или полный профан в этом вопросе.

Расскажите подробнее. Аргументируйте , особенно пункт "отношения SQL сервера" к обеспечению безопасности в сетях



Исправлено 1 раз(а). Последнее : dimapas, 14.03.18 14:22

dimapas
Расскажите подробнее

Что рассказать? Про криворукость идиота-админа? Так это вы нам может рассказать про таких из тех, кого видели. Мне настолько криворукие не встречались. В любом случае sql server тут совершенно не при чем, не он себя настраивает. Вот дбф в сети такого админа буду действительно доступны для любого изменения кем угодно и откуда угодно, в том числе и из интернета, даже не

Цитата:

использующего любую прогу , которая к нему коннектится.

А вот sql server даже в такой сети может от неё отгородиться, быть невидимым и не пускать к себе кого попало и много чего еще делать области безопасности и ограничения доступа.

ps: на профильных форумах в FAQ один из самых популярных вопросов "не могу подключиться к серверу", но вот пришел dimapas и сейчас нам откроет глаза на всю дырявость системы безопасности sql server и расскажет нам как сам sql server может сам себя в интернет выставить...





Исправлено 1 раз(а). Последнее : ssa, 14.03.18 14:26

Taran

dimapas
Мне нужно определиться с размером оплаты , сроками и целесообразностью этого занятия для себя.

Вот именно, "целесообразностью этого занятия для себя".
Насколько я понял ты порядка 20 лет не занимался фоксом. И оно тебе надо? Худо бедно конечно решишь задачу.
Ну, а дальше? Куда девать полученные знания за этот период?
Ну и, как говорится, ремонт нельзя закончить, его можно только остановить.
Все-равно в программе останутся слабые места. Ни дай бог новая версия понравится, то все, ты прилип. ;)
Посвящать сейчас свою жизнь изучению фокса - не самое лучшее занятие.

И конечно 8 месяцев. Народ будет крайне озабочен и нервозен. Такую задачу надо делать аврально.
Упал - отжался, выдохнул. Проект сдал - закурил и выпил шампанского.
Так или иначе нужно погрязнуть в существующем проекте. А ежели у тебя есть и текущие заботы/работы, то это крайне затруднительно.

Фоксом не занимался почти 10 лет.
Да , сижу и думаю , оцениваю.

dimapas
Аргументируйте

Нет уж, батенька, это вам придется аргументировать ваш бред. Процитирую:

Цитата:

Но с другой стороны , SQL-сервер , по моим наблюдениям , ещё стрёмнее. Доступ к нему на запись вообще с любой точки сети может быть осуществлён , включая WEB. C любой учёткой и любого пользователя , использующего любую прогу , которая к нему коннектится.

Откройте нам и всему миру глаза, а то мы ж вчерашние студенты, еще ничего видели и не знаем.

ssa

dimapas
Расскажите подробнее

Что рассказать? Про криворукость идиота-админа? Так это вы нам может рассказать про таких из тех, кого видели. Мне настолько криворукие не встречались. В любом случае sql server тут совершенно не при чем, не он себя настраивает. Вот дбф в сети такого админа буду действительно доступны для любого изменения кем угодно и откуда угодно, в том числе и из интернета, даже не

Цитата:

использующего любую прогу , которая к нему коннектится.

А вот sql server даже в такой сети может от неё отгородиться, быть невидимым и не пускать к себе кого попало и много чего еще делать области безопасности и ограничения доступа.

ps: на профильных форумах в FAQ один из самых популярных вопросов "не могу подключиться к серверу", но вот пришел dimapas и сейчас нам откроет глаза на всю дырявость системы безопасности sql server и расскажет нам как сам sql server может сам себя в интернет выставить...

не видели криворуких сисадминов ? Я вам рассказывать не буду , наберётесь опыта - увидите.
Что за "популярные вопросы на форумах про невозможность подключения к SQL серверу и его "отгораживание" ?? Это что , аргумент в пользу его защищённости ?

Послушайте ... , любезнейший. Вам простой реальный пример (с этого же предприятия): Есть учётка , доменная , есть учётка для подключения к SQL-серверу. Учёток много. ОНИ ИЗВЕСТНЫ. МНОГИМ! Доменную можно узнать прямо на компе (не некоторых даже на обоях рабочего стола текст , чтобы тётки незабыли , компы включены круглосуточно , почти не перезагружаются , за каждым 4 сменных работницы , которые категорически не могут вспомнить пароль через 2 месяца после случайной перезагрузки ) , а учётка на SQL любезно сисадмином продублирована по имени , потому как разработчику одной проги было удобно разграничивать рабочие места и брать имя пользователя именно из сеанса Win. Пароли "упрощены" до безобразия , потому как пользуются ими женщины бальзаковского возраста. Кроме того , все пароли прописаны локально в реестре на автологин. Заходи , читай - не хочу.

Что же тогда Вам может помешать к нему (к SQL- серверу) подключаться ? Гордыня и напыщенность своими знаниям про безопасность ?

В общем , я не хочу тут общаться не по теме , а тем более спорить с переходJм на личности. Рассказал вам про реальный пример , если вы никогда такого не видели ... Всего вам хорошего.



Исправлено 2 раз(а). Последнее : dimapas, 14.03.18 15:04

Да, как все запущено, это не сарказм, а сожаление. Но переломить ситуацию в вашмх руках, напишите прогу так, то бы она не читала пароли с диска, реестра это заставит их вводить руками.

А вообще-то, вам помимо целевого функционала придется еще создать фраймворк под эту задачу, а это считай еще полгода, а то и больше.

Изучить SQL сервер, это как минимум год, что бы бегло ориентироваться, но не знать его досконально.





Исправлено 2 раз(а). Последнее : PaulWist, 14.03.18 15:00

dimapas
не видели криворуких сисадминов ?

Видел. И не одного. Но не настолько криворукого.

Цитата:

Я вам рассказывать не буду , наберётесь опыта - увидите.

Вы большой знаток моего опыта?

Цитата:

Что за "популярные вопросы на форумах про невозможность подключения к SQL серверу и его "отгораживание" ?? Это что , аргумент в пользу его защищённости ?

Это аргумент в пользу кривости ваших знаний по сему вопросу.

Цитата:

Послушайте ... , любезнейший. Вам простой реальный пример (с этого же предприятия): Есть учётка , доменная , есть учётка для подключения к SQL-серверу. Учёток много. ОНИ ИЗВЕСТНЫ. МНОГИМ! Доменную можно узнать прямо на компе (не некоторых даже на обоях рабочего стола текст , чтобы тётки незабыли) , а учётка на SQL любезно сисадмином продублирована по имени , потому как разработчику одной проги было удобно брать имя пользователя из сеанса Win. Пароли "упрощены" до безобразия , потому как пользуются ими женщины бальзаковского возраста. Кроме того , все пароли прописаны локально в реестре на автологин. Заходи , читай - не хочу.

Что же тогда Вам может помешать к нему (к SQL- серверу) подключаться ?

Пипец аргументы... Типа "А вот к дбф-ам не подключится"... Расскажите это вырусам-шифровальщикам. Еще раз - какое отношение криворукость админа-идиота имеет к sql server'у и его системе безопасности?

Цитата:

Гордыня и напыщенность своими знаниям про безопасность ?

Кроме учеток и прочего из перечисленного выше есть еще кое-какие настройки на самом сервере. Но, опять же, не sql server виновен в идиотизме админа.

Цитата:

В общем , я не хочу тут общаться не по теме , а тем более спорить с переходJм на личности.

Прелестно! Я только за. Вы прекращаете нести ахинею и мне не придется ее разоблачать в целях обеспечения безопасности неокрепших умов начинающих программистов, которые эжту ахинею могут прочитать и построить на них свою картину окружающего мира. Мучаться ведь потом будут.

Цитата:

Рассказал вам про реальный пример , если вы никогда такого не видели ...

Нечто подобное видел. Но тот админ недолго там работал. Очень недолго... В любом случае система безопасности sql server'а все равно тут не при чем. Это пример идиотизма админа и его начальства и к sql server'e имеет очень опосредованное отношение.

dimapas
и целесообразностью этого занятия для себя...p/s/: 400к никто не заплатит!

Целесообразность близка к нулю.

VFP мёртв, и он ни разу не 64-разрядный, и даже не Win7/8/10 совместимый - да, работает, но кое-как. Выйдет какой очередной патч и может запросто приказать долго жить - ну или что-то отвалится и тебе придётся это переделывать/чинить.
DBF-ы - это последнее на чём сегодня можно строить хоть какую-либо систему, тем более отчуждаемую (не ту которую ты собираешься всё время её работы пальцем подпихивать).
VFP не работает адекватно с досовскими dbf-ами. Т.е. даже если на VFP переписывать, придётся делать какие-то загрузки/выгрузки/синхронизации. Структура БД наверняка "обнять и плакать" - т.е. её тоже придётся перепроектировать.
Переписывание - это по сути написание НОВОЙ программы. От старой, если повезёт, можно взять "постановку задачи" - никакой код оттуда не поможет (даже для перехода на якобы "такой же фокс"), никакой "совместной работы старой и новой" программы нет и быть не может. Параллельная работа И там И там - с полным дублированием всех произведенных действий - да, может в теории, на практике таких "тёток" не найти которые согласятся 2 раза выполнять работу.
SQL - я бы трактовал шире - не только MSSQL. Серверов достаточно много, включая бесплатные. Но да, любой сервер требует админа минимально дружащего с головой - т.е. если там реально идиоты, то админить придётся тебе самому (и да, судя по жлобству клиента - забесплатно).

В общем если не готов "программировать за еду", посылай их всех в ...

Igor Korolyov
В общем если не готов "программировать за еду", посылай их всех в ...

Почти Есенин. ;)

Igor Korolyov
DBF-ы - это последнее на чём сегодня можно строить хоть какую-либо систему, тем более отчуждаемую (не ту которую ты собираешься всё время её работы пальцем подпихивать).
VFP не работает адекватно с досовскими dbf-ами. Т.е. даже если на VFP переписывать, придётся делать какие-то загрузки/выгрузки/синхронизации. Структура БД наверняка "обнять и плакать" - т.е. её тоже придётся перепроектировать.

Позвольте не согласиться. Работает VFP с досовскими DBF на ура , причём ещё и совместно с прогой под DOS. Т.е. в режиме реального времени у старой проги шаг за шагом можно отбирать функции (ввод данных, расчёт, печатные формы) не нарушая производственного процесса! 2 раза вводить не нужно. Делал так и на немаленьком предприятии, все остались довольны. Структура БД в этом случае волновать будет мало - ну кое-что дополнить придётся.

Насчёт "отчуждаемости" - запрашивают поддержку в будущем. Надолго.
Кроме того, там не одна такая прога ... всё это осталось в наследство от ушедшего на пенсию. Т.е возможно придётся переделывать в будущем что-то ещё.

Igor Korolyov
От старой, если повезёт, можно взять "постановку задачи" - никакой код оттуда не поможет

Поможет. Очень немного, но поможет. Не копипастом конечно ...

Igor Korolyov
VFP мёртв, и он ни разу не 64-разрядный, и даже не Win7/8/10 совместимый - да, работает, но кое-как. Выйдет какой очередной патч и может запросто приказать долго жить - ну или что-то отвалится и тебе придётся это переделывать/чинить.

Ну тут да , поддержки и продвижения лисы от Микрософт давно нет , будущее гарантировать нельзя. Но в настоящем VFP работает нормально или есть какие-то проблемы ? Какие ?



Исправлено 8 раз(а). Последнее : dimapas, 14.03.18 23:06

Taran

Igor Korolyov
В общем если не готов "программировать за еду", посылай их всех в ...

Почти Есенин. ;)

А Есенин попросил (спросил) бы за работу ПОБОЛЬШЕ ? За спрос ведь не бьют ...

Имеется:
1.Вопрос безопасности не стоит. Данные технологического характера (не интересны кому-то извне), доступ к компу посторонних практически невозможен.
И да , там скорее винты на сервере , где крутится MSSQL-сервер , развалятся от недостатка финансирования и такое уже там было! Плюс нагрузка на них часто близка к 100 процентам, что сулит перебои с быстродействием.
2.Вопрос параллельного функционирования двух прог решаем, операторы будут довольны.
3.VFP нормально работает на современных осях. Или я чего-то не знаю ?
4.Как оно будет в будущем ... - тут да, непонятно . Досовские проги конечно не работают на современной оси и что будет в будущем с VFP - вопрос.
5. 8 месяцев - достаточно для переделки проги в комфортном режиме.
6. Оплата ? - надо попробовать выторговать больше.
7. Таких прог не одна , в будущем скорее всего работа будет ещё. Плюс поддержка, всё это в совокупности доход. У нас регион не богатый, не Москва.
8. Вирус, питающийся DBF-ми в последнее время как-то не встречается. Перевёлся (не эволюционировал), наверно из-за отсутствия пищи.

В общем что, при недостаточной оплате смело отказываться ? Или отказываться сразу , даже не торгуясь ?



Исправлено 5 раз(а). Последнее : dimapas, 14.03.18 23:08

dimapas
Позвольте не согласиться. Работает VFP с досовскими DBF на ура , причём ещё и совместно с прогой под DOS.

Моё дело предупредить... Твоё - посмеяться, а потом горько плакать Индексы разрушаются на раз если менять таблицу и из FPD и из VFP. Оптимизация в 9ке вообще специально отключается для таблиц в "неродной" Codepage - т.к. иначе будут некорректные результаты в некоторых запросах.

dimapas
Ну тут да , поддержки и продвижения лисы от Микрософт давно нет , будущее гарантировать нельзя. Но в настоящем VFP работает нормально или есть какие-то проблемы ? Какие ?

Ненормально он работает начиная с висты - пока глюки небольшие, что-то обходится, что-то можно терпеть. Банальный тулбар или docable форму (включая окна IDE) потаскай по экрану.
На форуме и про более серьёзные глюки писали.

В любом случае начинать что-то писать на фоксе не имея готового фреймворка - пусть простенького - это удвоит время разработки. Есть ли у тебя такой фреймворк (наработки для "типовых" задач) - сомневаюсь...
Нет, оно, конечно, можно и на BROWSE-ах программу сделать - тем более "за копейки" Только называть это программой... Ну у меня язык не повернётся

Igor Korolyov
Моё дело предупредить... Твоё - посмеяться, а потом горько плакать Индексы разрушаются на раз если менять таблицу и из FPD и из VFP. Оптимизация в 9ке вообще специально отключается для таблиц в "неродной" Codepage - т.к. иначе будут некорректные результаты в некоторых запросах.

Индексы не разрушаются , проблем с codepage нет. Правда применял такую схему (параллельной работы) на VFP 6.0 , но с dbf-ками немаленького объёма, число записей в некоторых шло на миллионы. Работало 100%.
Что с VFP 9.0 не так ? Может я не в курсе ...

Igor Korolyov
Ненормально он работает начиная с висты - пока глюки небольшие, что-то обходится, что-то можно терпеть. Банальный тулбар или docable форму (включая окна IDE) потаскай по экрану.
На форуме и про более серьёзные глюки писали.

Я имел ввиду работу готового *.exe. Он работает. Спецом прямо сейчас проверил, скомпилированный в VFP 6.0 преспокойно запускается на WIN 10 64 bit со всеми обновками, всё работает и работает ХО-РО-ШО! С досовскими таблицами и без включения всяких режимов совместимости.
Приложил скрин экрана , как убрать лишние "отпечатки" экрана в среде разработки. Но да, факт есть , согласен.
p/s/ А Вы видели баги в "современных" средствах разработки ?

Igor Korolyov
В любом случае начинать что-то писать на фоксе не имея готового фреймворка - пусть простенького - это удвоит время разработки. Есть ли у тебя такой фреймворк (наработки для "типовых" задач) - сомневаюсь...
Нет, оно, конечно, можно и на BROWSE-ах программу сделать - тем более "за копейки" Только называть это программой... Ну у меня язык не повернётся

Наработки есть, просто нужно рыться, искать , вспоминать, т.к. давно это было ... Но и построить что-то заново - можно.
BROWSE ? - да легко! Прямо из меню сверху Ну а что они хотели за такие деньги , картинку с уникальным дизайном и анимацией?
Ну можно этот же BROWSE встроить в форму (в GRID, кажется так делал) - выглядеть будет поцивильнее.

КАКИЕ ЕСТЬ ПРОБЛЕМЫ ЕЩЁ ?
Впрочем да, основную проблему уже увидел. Это расхожая фраза-клише "ФоксПро мёртв". И с ней очень трудно будет бороться , т.к. это уже устоявшаяся предвзятость. Пусть даже и эта СУБД до сих пор работает без проблем и лишних сложностей, что собственно и нужно конечному заказчику.



Исправлено 2 раз(а). Последнее : dimapas, 15.03.18 02:21

Поскоку сам из провинции и знаю как "у нас тут" с доходами-зряплатами ... если имеется опыт - то почему бы и не заработать копеечку дополнительную? Уж по скорости разработки фокс весьма-весьма.
З.Ы. Правда я бы параллельно и с dbf-ов бы слазил, табличка за табличкой - это уменьшило бы геморой в дальнейшем ... но это ИМХА

Могу поделиться реальным опытом выполнения подобной работы. Коротко об истории: в 1992 - 1997 гг работал в негосударственном пенсионном фонде, была разработана АСУ для фонда на FPD. Объем ~ 200 пунктов меню, ~50 форм для ввода информации и около 200 отчетов. В 2007 г. пригласили переделать АСУ на VFP. Уже тогда решение использовать VFP было сомнительным, но ценник на АСУ НПФ современной тогда разработки начинался от 5-6 млн + необходимость допиливать стандартную АСУ к нуждам конкретного НПФ + большой геморрой на переход - это заказчику казалось неприемлемым. Перевод удалось осуществить в основном примерно за полтора года (работал только я один), при этом около 4 месяцев было потрачено на разработку стандартных (для этой АСУ) элементов интерфейса; в это время также вошла и разработка новых блоков, так как законодательство изменилось. Использовать базы данных VFP было невозможно, так как в течение всего времени перехода часть персонала работала с данными через DOS-программу, а часть - через VFP-программу, поэтому все данные остались в DBF-ах. Тексты DOS-программ использовались только в части расчетных алгоритмов, вся интерфейсная часть удалялась. Помогало также хорошее знание предметной области, без этого времени ушло бы больше. Платили среднюю по тем временам ЗП программиста по Москве.

igoza
Могу поделиться реальным опытом выполнения подобной работы. Коротко об истории: в 1992 - 1997 гг работал в негосударственном пенсионном фонде, была разработана АСУ для фонда на FPD. Объем ~ 200 пунктов меню, ~50 форм для ввода информации и около 200 отчетов. В 2007 г. пригласили переделать АСУ на VFP. Уже тогда решение использовать VFP было сомнительным, но ценник на АСУ НПФ современной тогда разработки начинался от 5-6 млн + необходимость допиливать стандартную АСУ к нуждам конкретного НПФ + большой геморрой на переход - это заказчику казалось неприемлемым. Перевод удалось осуществить в основном примерно за полтора года (работал только я один), при этом около 4 месяцев было потрачено на разработку стандартных (для этой АСУ) элементов интерфейса; в это время также вошла и разработка новых блоков, так как законодательство изменилось. Использовать базы данных VFP было невозможно, так как в течение всего времени перехода часть персонала работала с данными через DOS-программу, а часть - через VFP-программу, поэтому все данные остались в DBF-ах. Тексты DOS-программ использовались только в части расчетных алгоритмов, вся интерфейсная часть удалялась. Помогало также хорошее знание предметной области, без этого времени ушло бы больше. Платили среднюю по тем временам ЗП программиста по Москве.

НЕ КИСЛО! Поработали заметно ...
У меня опыт намного поменьше и помоложе. Делал переписвание проги под расчёт ЗП на предприятии численностью 3.5к человек , плюс по мелочёвке всякой . 10+1 бухгалтер + доп.прогмер (для подпихивания пальцем старой проги). Всё прошло успешно, но именно благодаря параллельному режиму. Иначе даже не представляю как.
Платили двойную ЗП, но не по Москве, конечно.



Исправлено 1 раз(а). Последнее : dimapas, 15.03.18 11:22