Вопрос не совсем по Билдеру, скорее по БД. Мож кто знает.
Раньше я вносил туда новые записи с помощью TQuery с запросом Insert into table(fkey,fname,fvalue) values(:k,:n,:v). А новое значение ключевого поля получал предварительно получив макс значение этого поля и прибавив 1. Затем я прочел, что генерация нового значения ключевого поля таким способом не годится, если хочешь организовать одновременный доступ к данным по локальной сети (а в дальнейшем это предполагается). Поэтому, я сделал поле fkey аутоинкрементным и пытался вносить новые записи с помощью след запроса: Insert into table(fname,fvalue) values(:n,:v) (думал, что значение ключевого поля будет автоматически генериться). Однако при попытке внести новую запись база пишет: "Key Violation". Вопрос у меня такой - как обеспечить аутоинкрементацию ключевого поля? С нетерпением жду ответов. (База данных - Paradox)
Но все это только тогда, если в Paradox-е не можно создать триггер. Этого я не помню. Но в Foxpro триггер создается и оба desktop системы.
В Paradox'е триггеров нет. Придется читать доку по автоинкрементным полям.
А вообще, как показала практика (к счастью, не моя), использование автоинкрементых полей в Парадокс часто приводит к разрушению файла БД. Одно время на Borland Community под эгидой Borland была статья, в которой говорилось, что использование автоинкрементных полей в качестве первичного ключа таблицы при некоторых условиях может привести к разрушению структуры таблицы. Это является следствием бага в Paradox. Borland об этом знает, но поскольку поддержка Paradox уже давно прекращена, баг исправляться не будет. Можно сказать, что он стал "документированной фичей".
Поскольку по своей сути автоинкрементные поля предназначены именно для использования в качестве ключевых, отказ от их использования фактически означает отказ от использования автоинкрементных полей вообще.
Если планируется использовать базу в многопользовательском режиме, я бы советовал забыть про Paradox и посмотреть в сторону небольшого, но полноценного сервера БД. Например, того же Interbase.
insert into tab(fkey,fname,fvalue) values(NULL,:n,:v).
у меня так работает
Так, как предложил sedegoff
insert into tab(fkey,fname,fvalue) values(NULL,:n,:v)
в случае с аутоинкрементом делать нельзя, т.к. такое поле не редактируется.
А нужно делать так, как я писал в первом посте.
Я сделал новую таблицу, и все заработало.
Однако, после того как я установил мин. значение аутоинкрементного поля в 0, пошли глюки - база начинает аутоинкрементацию для новых вставляемых записей с нуля, это при том, что записи в таблице уже есть! Отсюда глюк! Причем если в существующей таблице убрать мин. значение и даже сделать table repire, баг не уходит :).
Кто-нибудь что-нибудь понял :)?
Прав smartsoft (я даже собственно глюк обнаружил - см. ниже) и не прав sedegoff.
Вообще-то я имел в виду не тот глюк, но это только начало. ;)
insert into tab(fkey,fname,fvalue) values(NULL,:n,:v)
в случае с аутоинкрементом делать нельзя, т.к. такое поле не редактируется.
У SQL-серверов есть такое понятие, как поля, изменяемые на сервере (например, триггером). В этом случае компоненты, работающие с сервером, должны обеспечивать т. н. "returning values", т. е. получение данных с сервера на клиент, после того как они были сгенерированы на стороне сервера.
Не могу сказать точно, возможно, в BDE этого нет. Но с другой стороны, Paradox - тоже не сервер БД. Читай доку.
А вообще, из сказанного мной выше выходит, что автоинкрементные поля нельзя использовать в реальной базе данных. Надо или перейти на серверный вариант, или попробовать найти другой формат настольной БД, поддерживающий автоинкрементные поля. Например, MS Access. Правда, для доступа к нему, скорее всего, придется использовать ADO, а в Дельфи это еще больший геморрой, чем BDE.
Последний вопрос в этой теме. Smartsoft советует перейти на InterBase, и, видимо, это правильно. На парадоксе я пишу потому что наша работа приобрела лицензионную версию этой БД, а мы собираемся продавать продукт. Я посмотрел в инете и понял (может быть неправильно), что InterBase распространяется бесплатно.
Да, только так и придется делать. Несомненным плюсом Interbase еще является то, что для доступа к нему можно использовать родные компоненты (кажется, они называются IBX). Соответственно, BDE отпадает полностью, и геморрой, связанный с ним, тоже.
Насколько я знаю, есть несколько версий IB, разрабатываемых разными группами разработчиков. Среди них есть как платные, так и бесплатные, с открытыми исходниками. Что-то конкретное посоветовать не могу - сам не использовал. Возможно, это смогут сделать другие, кто непосредственно сталкивался.
Начать можно с сайта Borland, перейдя на ссылку InterBase. Или можно ввести в Google искомое слово и получить кучу ссылок.
Теперь по поводу
insert into tab(fkey,fname,fvalue) values(NULL,:n,:v)
Да погаричился для Paradox yt rfnbn
но это правила хорошего тона - так должно быть (InterBase/Firebird).
Последний вопрос в этой теме. Smartsoft советует перейти на InterBase, и, видимо, это правильно. На парадоксе я пишу потому что наша работа приобрела лицензионную версию этой БД, а мы собираемся продавать продукт. Я посмотрел в инете и понял (может быть неправильно), что InterBase распространяется бесплатно. Так ли это и если так, то где эту самую InterBase брать? Много ли в ней глюков?
На основании GPL распространяется Firebird - на сегодня точный клон Interbase6,5 c исправленными багами. Работает нормально и стабильно. Если необходимо распространять свой продукт ты можешь это делать согласно вышеуказанной лицензии - т.е. ты не имеешь права закрывать исходники сервера или каким то образом изменять лицензирование. Есть еще Yaffil - российский клон тогоже ИБ. От остальных отличается возможностью использовать средства авторизации и оптимизации WinNT. Правда автоинкремента ни в одном из них нет...:) зато есть генераторы триггеры и куча дополнительных наворотов. Кстати Yaffil - по аглицки дятел зеленый.
ИМХО использование автоинкремента в базе верный путь в тупик. Триггер можно сделать не активным или изменить его логику, генератор выключить, а вот сабж будет висеть как мЭч дамоклов ...:)
Ну а о идеях с таблицами и файлами в которые надо записывать значения - такое имело смысл делать на Clipper'е, выхода другого не было. Но спустя 15 лет использовать не самое лучшее решение даже для тех времен...хм
ИМХО использование автоинкремента в базе верный путь в тупик. Триггер можно сделать не активным или изменить его логику, генератор выключить, а вот сабж будет висеть как мЭч дамоклов ...:)
Обеспечение целостности логики приложения на стороне сервера - задача программиста и/или администратора БД, работающего над задачей. Несогласованность внесения изменений в скрипты и объекты на сервере однозначно классифицируется как "кривые руки". А простые пользователи никогда не должны работать с базой на низком уровне, по той же самой классификации ;)
Согласен, "хм". ;)
Для первычных ключей на серверах, как раз используют автоинкремент. В Interbase он называется генератор, а в Oracle последовательность.
Да я что против? Мне показалось, речь шла о именно о типе поля в Paradox и ему подобных.
Ты прав. Но представ ситуацию. Делают баланс в бухгалтерии и bug. И крутой программист говорит: я это исправлю, но купите мне это и то, и тогда я все перепишу. А кустарные методы я использовать не буду, это ниже моего уровня.
Если же исходить из того, что это не внутрифирменная программа, а программа предназначенная на продаж, то уже хотя бы 10 лет серверам альтернативы нет.
Ну все же одно дело баг в конкретной бухгалтерии - другое дело поставка продукта на основе устаревшего сервера (опять же если речь все еще идет о Paradox. ) :) Тем более что в случае с IB(Firebird,Yaffil)покупать ничего пока не надо.