Можно просто поставить в поле праймери индекса табдицы default=reccount() и после аппенда делать replace sklad with 'склад'+alltr(str(id)). Тогда точно не будет совпадающих номеров складов Но тут уж такой прикол получится: если есть 3 склада и удалишь второй, то потом склад2 уже не создашь - только склад4.

NewID - не вопрос, но только для тех, кто работает с фоксом после семерки. Я обычно юзаю именно такой метод, какой я описал - именно реккаунт. Но!!!! всегда в программе делается пункт меню "сервис" - в котором есть и конфиг программы (пути к базам прописать) и всегда есть пункт (я так всегда делаю) - типа переиндексация базы или чистка, если хотите. Так там висит код, после которого и записи удаленные убираются и происходит ВСЕГДА проверка остающихся в базе данных. А там уже можно при проверке любые варианты рассмотреть - тут уж от задачи зависит, какие резы и данные, кот в дальнейшем вводиться будут. Так что реккоунт работает гут, но только при условии, что не программер местный каждый раз будет паки запускать и гробить всю нумерацию, а цивильно - юзер жмет пункт меню и выполняется чистка базы, переиндексация - да че угодно, но главное это в сервисах предусмотреть. Если такие вещи (типа переиндексации и пака) в меню предусмотреть - то вмешиваться в базу ручками и не надо будет. Единственное - пишешь инстракшен на листике и раздаешь юзерам, а лучше только юзерам с правами админов, и все. Они знают - раз в месяц надо запустить такой-то пункт меню и все будет супер гут, база будет почищена и раотать будет быстрее. Так что здесь проблем не метода, каким я пользуюсь, а именно сервсных функций, кот будут в программе.

2 Urri

Да все такой метод предусматривает - пакуй и удаляй на здоровье. Только я еще раз говорю - не ручками через фокс, а напиши сервисную функцию в проге. Привожу пример:

есть таблица "справочник материалов", есть вторая таблица "сметы".
Метериалы:
mat_id mat_name
1 цемент м400
2 цемент м500
3 кирпич

Сметы:
smet_id smet_name mat_id
1 смета1 1
1 смета1 2
1 смета1 3
2 смета2 1
2 смета2 2

Удаляем цемент м500. перепаковали базу, после пака пробежали по табличке и последовательно перенумеровали коды:

mat_id mat_name
1 цемент м400
2 кирпич

Теперь если дефолт в материалах стоит reccount()+1, то будет снова добавляться материал с кодом 3. Так вот: после пака материалов нужно просто еще пробежать по таблице сметы, удалить все материалы с кодом 2 и там где материалы с кодом 3 - заменить его на 2. Все - работать будет великолепно.
А основание делать паки и переиндексации программно есть, причем очень веское! Если ты написал прогу для своей компании и она только у вас активно используется - то можно и ручками перепаковывать. А если ты ее сделал на заказ и она используется где-то далеко компанией, в кот и программеров-то нет? Кто там и что ручками будет через фокс делать? А перепаковывать и переиндексировать базу время от времени надо. И че делать-то? Они тебе по почте будут несколькогигабайтную базу слать? Не выход. А если есть сервисная функция такая - то даже распоследний юзер (секретарша шефа ) сможет нажать кнопочку "переиндексация", если у него будет в инструкции это написано.

ЗЫМ насчет примера - никто конечно же со сметами так не работает Если в ней был цемент, то он и должен остаться, а не на песок заменяться или удаляться вообще, так что не судите строго Это просто первый пример, кот пришел в голову.

2 Igor Korolyov

А что там отвечать даже? Вообще не вижу проблемы - сделал себе представление, добавляй и удаляй что надо. Надо сохранить эти изменения в главной таблице и подчиненных? чем вопрос: никаких проблем нет. Делаешь аппенд в главную, в подчиненные - можно триггеры для таблиц прописать или в самом коде указать что и куда повставлять, где сложность? Удаление - то же самое. Может я и не прав, конечно, но приведи хоть пример, где могут вылезти партаки? Или воопрос сформулируй поконкретнее - отвечу более предметно.