Резюме:

Подобные вопросы, такие как получение ID, возникают только в том случае, если программное обеспечение пишется "на коленке" в дилетантской среде, без бизнес-аналитики, постановки и технического задания. Что не удивительно, т.к. большинство FVP программистов используя удивительные свойства VFP зачастую в одном лице представляют и бизнес аналитика и постановщика да и саму "фирму" (человек - фирма). Именно безграмотный подход к созданию системы порождает вопросы обсуждаемые в данном топике на протяжении уже 9-ти страниц... Это показатель того насколько "запущен" процесс создания бизнес приложений в среде VFP в России. Не удивительно, что программисты VFP настолько низкооплачиваемы в сравнении с программистами других категорий. Это показатель низкой культуры программирования в VFP. Не смотря на огромные возможности VFP, в России этот продукт недооценен, возможно это результат работы таких вот VFP программистов...
Грамотная постановка задачи позволяет решать вопрос этого топика без дополнительных извращений обычно используемых дилетантами.

Для того, чтобы не появлялось вопросов поднятых в данном топике, при проектировании и программировании программного обеспечения необходимо соблюдать следующие правила:

1. каждая запись должна иметь автора и дату создания
2. любое исправление записи должно фиксироваться в журнале исправлений
3.журнал исправлений(модификаций) должен отражать:
а)дату исправления
б)автора исправления
г)имя поля
д)старое значение поля
е)новое значение поля
ж)идентификатор исправленной записи
з)идентификатор таблицы, базы, приложения
и)идентификатор рабочей станции с которой произведена модификация
4. каждый пользователь должен однозначно идентифицироваться системой
5. система должна позволять совершать откат ошибочных операций на основании журнала модификаций
7. система должна быть стабильной, иметь дружественный интерфейс, легко настраиваться
8. система должна иметь администратора

Соблюдение перечисленных правил позволит вам создавать действительно стоящие приложения на VFP, которые будут стоящими не только в смысле качественном, но и в смысле денежном (количественном).

Вот такие выводы и пожелания.

С уважением FoXXX.

:))

ВладимирМ FoXXX
Опять!? Большая часть из этих 9 страниц посвящены лично Вам и разбору Ваших ошибок! Поэтому, насчет "безграмотности" и "дилетантизма" ...

Вы описали СВОЮ постановку задачи. Какие есть основания предполагать, что ВСЕ задачи имеют такую же постановку? Не "должны", а именно "имеют"? Ведь под термином "должны" Вы подразумеваете "должны в МОЕЙ постановке задачи".

Практически каждый из описанных пунктов, как минимум, можно поставить под сомнение. Все зависит от конкретной постановки задачи.

Постановка бывает грамотной (научной) и безграмотной (ненаучной) - вот и вся разница..

а по поводу "моих ошибок" это вы слишком.. я же не называю ваши разработки ошибкой, я говорю о безграмотности в вопросах формирования ТЗ, в вопросах анализа, ошибки это правописание, а анализ - искуство..

можно писать без ошибок но не быть писателем, и можно писать с ошибками, но быть им..

так и програмист, либо он делает вещи, либо нет и не важно с ошибками или нет, ошибки можно исправить, а кривое приложение - нет.. его можно только переписать заново..

ВладимирМ

не 9 пунктов, меньше, несколько вычеркнул, чтобы не нагружать.

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

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

GustafСтолько копий сломали ...
а нельзя ли после tableupdate воспользоваться коммандой REFRESH() ?

т.е. после tableupdate выдаем REFRESH(1,1) - по идее должна обновиться всего 1 запись (текущая вместе с полем id) без всяких go bottom?

указатель слетает..