Собственно вопрос, как после удаления всей информации из таблицы установить Primary Key = 0

Например в MS SQL есть команда которую мона выполнить, чтобы учтановить PK в 0

если у пк стоит автогенерация, не все ли равно с какого значения она начнется?

это же парадокс!... ;)
у нас проблема на старом была (в прошлом веке еще :)), значений авто инкременту не хватало (там были версии с до 32тыс значений), ну вот если у него такой... тоды ой.

> как после удаления всей информации из таблицы
а как удаляется? DbiEmptyTable в принципе должно все чистить, т.к. делается пересозданием (самый быстрый способ, удалить и создать, чем миллион "делитов" с перераспределением страниц...).

EmptyTable вроде бы сбрасывает в 0 и как сказали самый быстрый метод

> Автоинкремент там давно 4-х байтный.
в прошлом веке? в dos версии?

> в dos версии?

Во времена Dos Дельфи не было. А что касается времен Дельфи, то это Парадокс 5 (или может 4 в Д1). А там уже 4-х байтный.

> Во времена Dos Дельфи не было.
dos и ныне живой (пройди по окрестным магазинам по заглядывай в монитор, повезет встретишь "в живую"), и некоторым с ним приходилось работать аж до 2006г. и с таблицами им/прогой на нем сделанными в Дельфе работать.

> А что касается времен Дельфи, то это Парадокс 5 (или может 4 в Д1). А там уже 4-х байтный.
вопрос твой? ты точно знаешь версию, или просто "лишь бы ляпнуть"?

> вопрос твой? ты точно знаешь версию

Нет. Вопрос не мой. И версию не знаю.
Просто вспоминая молодость помню, что у меня тоже "чесалось" сбрасывать автоинкремент в ноль при очистке таблицы. Но это была только "моя личная проблема", а не проблема Парадокса.
:)

а у нас была именно проблема парадокса, т.к. из-за этого кассы "вставали", пока не нашли и не "пофиксили".
+ это была проблема стиля работы, т.к. кассовая прога вместо создания новых справочников "таскала их с собой", для "надежности", и по нужде распаковывала в готовое каталог. ну а так как в архив клали тоже "проверенное/надежное" то попадали туда таблицы тестеров "проверенные/перепроверенные" с установленным авто инкрементом например на 28 тыс... (хотя хороший магазин, и с "0" забивал за пару месяцев, т.что это не основное). в общем пока не сделали "помесячное"/"понедельное" логирование, с действительно чистым автоинкрементом, проблемы вылазили довольно регулярно (+ ко всему не всегда превышение приводило к ошибкам, иногда просто сбрасывалось в минус).

Избегать авто-инкремента всеми силами - делов-то.

ага, а еще были проблемы со строками - избегать всеми силами строк, проблемы с бекапами - избегать бекапов, указателями-указателей, базами, операционкой, ... ets.
в итоге единственное что остается, это счеты... ну до первого раза когда разгневанный "бух" ими тебя по "чайнику" долбанет (ага, проблема)... после остается только увольняться, и в дворники.

> Избегать авто-инкремента всеми силами - делов-то.


А что же вместо них использовать?

>_Юрий   (28.02.11 21:15) [14]
>> Избегать авто-инкремента всеми силами - делов-то.
>А что же вместо них использовать?

Мануальные декременты. Разве не понятно?

А если серьезно, то можно и свой автоинкремент сделать. Ничего сложного, зато полный контроль зад генерацией ключей.

Стандалон, при создании получающий max(ID) from tablename, и выполняющий автоинкремент программно.  А если очень хочется, можно поглубже копнуть, например, при старте просканировать таблицу на предмет присутствия "окон" в последовательности имеющихся первичных ключей с целью последующего выделения новых ключей из этих "окон", дабы рациональнее использовать числовой диапазон.

А если надо работать в многопользовательском окружении, то завести специальную табличку, в которой хранить NextID для каждой таблицы, либо общий для всей БД. В транзакции получать NextID, инкрементировать его (возможно, больше чем на 1, как вариант пакетного выделения первичных ключей), записывать значение обратно в таблицу ключей, а полученный ключ (группу ключей) использовать по назначению.

Противный   (28.02.11 22:15) [15]

О сколько нам открытий чудных
Готовит просвещенья дух

> Противный   (28.02.11 22:15) [15]
>


А зачем все это? Все ж уже сделано. Собственноручно изготовленный из подручных материалов велосипед всяко хуже серийного получится, да и времени лишнего съест

>> _Юрий   (28.02.11 22:40) [17] А зачем все это? Все ж уже сделано. Собственноручно изготовленный из подручных материалов велосипед всяко хуже серийного получится, да и времени лишнего съест

Сам подумай. Это не сложно, поверь. Надо только постараться. А потом даже легко и интересно станет.

>> Игорь Шевченко ©   (28.02.11 22:38) [16] О сколько нам открытий чудных Готовит просвещенья дух

Век живи, век учись. Ты пока еще только на половине пути. Так что... еще все спереди!

P.S. Ты, Игорь, лентяй и сноб.

> Во времена Dos Дельфи не было.

Это и ежику известно/ясно. Но Paradox уже не просто был, но даже поддердживался Borland Pascal  через DLL (естественно, толькои в защищенном режимеме) от ParadoxEngine.

>  Amoeba_   (01.03.11 00:19) [19]
>
>
> > Во времена Dos Дельфи не было.
>
> Это и ежику известно/ясно. Но Paradox уже не просто был,
>  но даже поддердживался Borland Pascal  через DLL (естественно,
>  толькои в защищенном режимеме) от ParadoxEngine.
>

Поясни.
Парадокс, конечно был во времена DOS. Но как он мог поддерживаться "Borland Pascal  через DLL", если самого механизма "Dynamic-link library" ещё не было?
Ну и тут ещё нужно спросить АП - когда Борланд купил (как всегда урезанную) версию Парадокс.

если уж такие траблы с идентити пк, тогда куда надежней createguid в качестве пк использовать...

> тогда куда надежней createguid в качестве пк использовать...
надежнее всего перейти с парадокса на что то современное, более "дуракозащищенное".

createguid

Который даст 128 недетерминированных псевдоуникальных бит. 16 байт для первичного ключа. 16 байт для каждого внешнего ключа. Индексы растут, производительност падает, пользователи в перерывах между запросами чаи гоняют.

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

Но это так, брюзжания о неэффективности GUID.

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

> Германн ©   (01.03.11 03:26) [20]
>
>
> >  Amoeba_   (01.03.11 00:19) [19]
> >
> >
> > > Во времена Dos Дельфи не было.
> >
> > Это и ежику известно/ясно. Но Paradox уже не просто был,
>
> >  но даже поддердживался Borland Pascal  через DLL (естественно,
>
> >  толькои в защищенном режимеме) от ParadoxEngine.
> >
>
> Поясни.
> Парадокс, конечно был во времена DOS. Но как он мог поддерживаться
> "Borland Pascal  через DLL", если самого механизма "Dynamic-
> link library" ещё не было?
> Ну и тут ещё нужно спросить АП - когда Борланд купил (как
> всегда урезанную) версию Парадокс.

В BP7 появилась версия компилятора для создания программ, работающих в защищенном режиме DOS, а также и DLL для него. Так что механизм "Dynamic-link library" уже поддерживался, единственно задействовался еще т.н. DOS-расширитель.
А соответствующая DLL с API для доступа к таблицам Paradox была в комплекте.

Люди Paradox 7 + D2006-DXE любая. Вы тут развели демогогию, а конкретных решений нема. Мона конешно такой код юзать:




Но при этом не переносятся связи таблиц.

Может быть их как то мона перенести ?

DbiEmptyTable тоже не помагает только зачищает таблицу :(

> Противный   (01.03.11 09:39) [23]

Автору ничего не надо писать, особо хитрозавороченного, надо просто перейти на промышленную СУБД, на бесплатную, с развитым набором типов и функций.

> Германн ©   (01.03.11 03:26) [20]

Не важно когда купил, в ДОС не было механизма ДЛЛ, только механизм оверлеев.

И если в Парадоксе и был автоинкримент в 16 бит, то в версии 3.0, а там вообще ничего не было, так даже язык программирования был макрорекордер. Жуть страшная. Нормальный, если можно так сказать Парадокс получился в версии 4.0

Ну его нафиг и нормальный и ненормальный, в скопе.

Кстати Борланд никогда не имел своей СУБД, Интернет компонент, Генераторов отчетов - это было или куплено (СУБД) или халява, когда решили, что на фиг покупать, когда вот оно бесплатное валяется.

Из СУБД они купили Парадокс, dBase, к которому в придачу дали ИБ (таже кадость как и Парадокс).

> DbiEmptyTable тоже не помагает только зачищает таблицу :(
тоды осталось "дропнуть" поле автоинкремента, и восстановить его после. с помощью alter table например.

кстати DbiEmptyTable не единственная функция там, там есть еще типа DbiTableRestructre... тоже меняет структуру типа alter table но возможностей должно быть больше, может удастся не удаляя поменять структуру.
да и с alter table можно не удалять, может получится, а просто поменять тип на простой int а после на автоинкремент... тогда индекс по этому полю не нужно будет восстанавливать.