Здравствуйте специалисты по FoxPro!
Решил обратиться за помощью по написанию программы. для меня слово "проект" гордо звучит
Начну с 0. Поэтапно...
Кратко о своих "способностях" по написанию на FoxPro: когда-то писал небольшие программки на версии 2.6.(изучал по книге автора Попова А.А. правда версия 2.0) - помню очень понравилось мне это занятие (в смысле программировать на Foxe).
прошло лет 15, вот решил силы попробовать, приобрел книгу "VFP 9.0 в подлиннике" авторов Клепинин и Агафонова. и...

как-то в растерянности с чего начать

Собственно, что хотел бы:
буду писать свои этапы, а от вас комментарии подсказки , где носом ткнуть и т.д.

задача: программа расчета сдельной зарплаты.
P.S. есть программа написанная на клипере(DOS), от неё я хочу использовать файлы DBF. В ней находятся данные по затратам и расценкам.

этап1: как я это вижу:
1. создаю таблицу общую куда буду все данные со всех таблиц пополнять, назовем - db,
2. создаю таблицу с месяцами - mes,
3. таблица с ФИО - FIO,
4. и есть таблица от клипер - FS1.dbf,
5. внизу таблица db. Командой GRID.


Создаю главную форму на которой будут:
1. TextBox1 и Button1 для выбора записи из таблицы fio
2. TextBox2 и Button2 для выбора записи из таблицы mes
3. 3 штуки TextBox3,4,5 и Button3 для выбора записи из таблицы FS1.dbf
4. Button4 для копирования содержимого всех TextBox на форме в таблицу db.

Сразу скажу, что файл FS1.DBF (клипер) я буду только считывать.

Вопрос: отношение между таблицами mes fio bd нужно делать?
а с файлом FS1 как быть, там индексный файл NTX.

NTX вряд ли удастся воспользоваться. Может, DBF читать в курсор, и в курсоре проиндексировать фоксом.

Начинать следует с чёткой постановки задачи, составления ТЗ (включая "что есть", "что надо", "как надо это считать").
Потом проектируют структуру БД - для VFP лучше использовать вариант не со свободными таблицами, а всё же с dbc. Структура должна отражать потребности задачи в данных, т.е. соответствовать ТЗ, и вовсе не обязана быть хоть как-то похожей на "то что было в клиппере".
Из "старых таблиц" данные можно только забирать (особенно учитывая что там ntx индексы) - хранить всё стоит в своих таблицах.
После создания БД можно начинать делать макеты форм - для начала без логики, чисто визуально - потом уже продумывать и саму логику, т.е. код реализующий то что прописано в ТЗ (то что надо "считать", плюс код просто поддерживающий ввод данных - типа создания новых записей, модификации существующих).
В VFP можно использовать связывание контролов (текстбоксов, комбо, не говоря уж о гриде) с курсорами - совершенно не обязательно писать код типа ThisForm.textbox1.Value = MyTable.SomeName и "обратный" REPLACE SomeName WITH ThisForm.textbox1.Value IN MyTable.
Для полноты управления следует использовать буферизацию, а так же представления, или, лучше, курсорадаптеры - чтобы работать не непосредственно с курсором полученным при открытии самой dbf таблицы, а курсором полученным в результате запроса к этой (а обычно сразу к нескольким) таблице - с ограничением по условиям отбираемых записей...

Также необходимо четко сформулировать ограничения целостности.

Это есть часть структуры БД.

Они пугают, все не так сложно.
- Создай табличку, "таблица с ФИО - FIO",
- попробуй создать форму с Grid, которая "показывает" эту табличку.
- потом немного измени форму, и показывай выборку из этой таблички
- реши, как ты будешь позволять пользователю выбирать записи в выборку (не все же записи показывать)
- создай форму редактирования записи из этой выборки, на которой стоит указатель в Grid
- реши, как (когда) ты будешь записывать произведенные изменения
- реши, как ты отличишь нажатие кнопки "Записать", а ни одно поле не изменено, что надо делать
... и подобные вопросы... Но пиши что-нибудь, пробуй, и вопросы сами возникнут.
... пройдет несколько времени...
(как сделаешь рабочий вариант, и предложишь его пользователям, они тебе еще 100 замечаний вынесут, ты их решишь, и все поймешь )

Igor Korolyov
Это есть часть структуры БД.

Оно-то да. Но есть еще ограничения в бизнес-правилах. Не уверен, что такого рода ограничения относятся к структуре БД.

Не слушай ихние споры, тов. новичек. Просто решай поэтапно свои "проблемы":

- "Решил обратиться за помощью по написанию программы. для меня слово "проект" гордо звучит"
проект - это просто набор файлов, из которых ты строишь свой EXE-шник. Фактически это DBF (PJX), в котором д.б. перечислены все твои PRG-шки и SCX-э (формы) и другие файлы, которые ты используешь. Также там назначена ГЛАВНАЯ PRG-шка, с которой начинается выполнение твоего EXEшника.
- Почитай про READ EVENTS - это единственная строка, она заставит работать формы (SCX) работать как формы твоего EXE-шника как отвечающие на нажатия кнопок (форма сразу не завершится, а только по команде ThisForm.Release)

of63
для меня слово "проект" гордо звучит

Ну дык. Проект - это практически живое существо.

Ребенок тоже живое, а матюгнешь, покажешь, и все просто становится, и сразу дружить начинает, знаем )

Хорошо сказал!..

Помоги новичку, на 2м фоксе живет, хочет соскочить )

Доб. Вернее использовал 15 лет назад... это было...конец 90х! А что написал товарищ новичок в 2000 году?



Исправлено 1 раз(а). Последнее : of63, 28.01.16 20:07

Я конечно не эксперт, а весьма посредственный любитель, но весьма рекомендовал бы сразу (!) отказаться от использования dbf/dbc в кач-ве базы данных, а выбрал бы что-нить "повзрослее" - это на начальном этапе увеличит обьем изучаемого, но зато сколько гемора позволит избежать в дальнейшем.

В силу ряда причин/факторов для меня такой "полувзрослой" БД стал Firebird - оченно удобно оказалось. Официально freeware, легко ставится даж неспециалистом как на винду так и на линух, уверенно держит большие (например у меня порядка 50 Гб - специфика задачи такая) обьемы данных, фокс с ней пркрасно работает через ODBC-драйвер, имеются удобные визуальные утилиты для администрирования БД (я пользую Ibexpert).
Думаю народ посоветует еще пару-тройку серверов БД по своему опыту.

Хороший выбор, сразу в сторону взрослых БД. Но бывает, что учебная задача, или заведомо бросовая, ну, или действительно, нормальная задача, когда можно позаботиться ио нормальной структуре (когда значения не дублируются, то это называется "нормализованная" структура, вроде), и о потенциальной "бесконечности" количества данных в БД

Я к тому - что ежели человек решил учиться на пркатике (а это на мой непросвещенный взгляд самое оно) - то лучше сразу изучать и нарабатывать себе полезный в дальнейшей практике опыт

Согласен, но и базовый набор функций с физическими DBF-ами надо не забыть, они полезеные

(Например, (это я уже о фоксе)) COPY TO файл TYPE AS 866 AS FOX2X позволяет особо одареным пользователям открыть эту DBF ы Excel, AS XL5 - делать XLS бкз наличия Excel)

Simple777
Оно-то да. Но есть еще ограничения в бизнес-правилах. Не уверен, что такого рода ограничения относятся к структуре БД.

Сложный вопрос - где заканчивается БД и начинается собственно прикладная программа. Тем более что "по науке" крайне редко всё делается. Настоящие многозвенные и, главное, многослойные программные комплексы - это не кучку формочек на dbf-ах наваять

Но с точки зрения проектирования - "бизнес-правила" (именно в части ограничений целостности, т.е. "правильности" данных) это часть структуры БД. Вот в части механизмов расчёта - "бизнес-логика" это уже не БД, хотя и может реализовываться средствами СУБД - например теми же ХП.
Просто если не хватает средств декларативного описания ограничений, тогда и приходится изолировать доступ к данным посредством набора ХП и через "права" не давать выполнять собственно insert/update/delete над таблицами - т.к. это как раз и вызовет нарушение "сложных" правил прописанных в ХП. Порой даже прямое "чтение" данных, т.е. select запрещают - хотя это уже и не относится к "целостности данных"...

(Давно, Максимов, высказал мысль, что БД д.б. как накопитель, мол, все равно весь набор правил "правильности" в триггерах вы не отследите, так че выеживаться. Я за эту точку зрения, предписания в БД о правильности - слишком слабый язык описания "правильности". Реальноя правильность - не выразима на элементарном уровне - это дело приложения... Ну, можно немного выложит проверок и в триггеры, ну так, для самоуспокоения)

Думаю истина где-то посередине )))

В реальности у меня часть логики в БД часть в приложении(клиенте) ... понимаю что идеологически это не совсем правильно - но так уж сложилось ...
Если бы сейчас начинал новый проект - то попытался бы максимум логики/доступа запихать в БД.



Исправлено 1 раз(а). Последнее : AndyNigmatec, 28.01.16 21:28

(Когда пишешь формулу, предписание, то среднего, нет, надо высказывать определенное высказывание, как ROUND(X, 0), "мелкие" решения важны, как и "крупные")