эмуляция поля autoinc

← →
mixam © (2004-06-01 09:17) [0]

в парадоксе есть тип поля autoInc - вот меня он не устраивает т.к. нарашивает значение после post, а мне надо знать значение во время insert

← →
DenK_vrtz © (2004-06-01 09:23) [1]

Варианты:
1.Если система однопользовательская - то перед insert - select max(id)...
2.Отдельная таблица-счетчик

← →
Alexandr (2004-06-01 09:29) [2]

стыдно в 21веке начинать писать базы банных на парадоксе.

← →
mixam © (2004-06-01 09:31) [3]

Да мысль, а пример виртуального (кодом) создания запроса с полем id можешь дать. Буду благодарен.

← →
DenK_vrtz © (2004-06-01 09:38) [4]

>Alexandr (01.06.04 09:29) [2]

ничего постыдного в этом не вижу! Все с чего-то начинали.

>mixam © (01.06.04 09:31) [3]

я ж написал запрос :) Но автоинкрементное поле, я считаю, надежнее.

← →
Anatoly Podgoretsky © (2004-06-01 09:51) [5]

Если не устраивает авто, то номера присваивай сам, можно получать последний номер как указано [1] правильно работает только в случае работы одного экземпляра программы.
Нужен ли именно номер? Что он за собой несет?

← →
Sandman25 © (2004-06-01 10:00) [6]

Если есть естественный ключ (уникальное поле или совокупность полей), то можно узнавать id вставленной записи сразу после insert с помощью select id from mytable where my_unique_field = "my_value"

← →
Anatoly Podgoretsky © (2004-06-01 10:06) [7]

Если есть естественный ключ то искуственный может быть и не к чему, разве что для экономии места или стабизации записи.

← →
Sandman25 © (2004-06-01 10:07) [8]

[7] Anatoly Podgoretsky © (01.06.04 10:06)

Естественный ключ может быть изменяемым (фискальный код или номер паспорта, например). Тогда будут проблемы при update связанных таблиц.

← →
Alexandr (2004-06-01 10:15) [9]

> DenK_vrtz © (01.06.04 09:38) [4]
> >Alexandr (01.06.04 09:29) [2]
>
> ничего постыдного в этом не вижу! Все с чего-то начинали.

я еще с ДВК начинал. Что это меняет?
Сейчас НЕТ НИКАКОГО СМЫСЛА что-то писать на парадоксе.
Мало того, что это глючно, так еще и очень тяжело. Вон чувак уже с первой проблемой столкнулся.
Эти все проблемы уже давно решены в нормальных СУБД, мало того, с ними работать проще, ресурсов сравнительно одинакого, если еще не меньше. Назовите хоть один аргумент в пользу парадокса по сравнению с клиент-серверными СУБД.

← →
-=alive=- (2004-06-01 10:23) [10]

Есть аргумент, переносимость на другие машины.

← →
Alexandr (2004-06-01 10:24) [11]

А что, другие перенести нельзя?
Или Yaffil Personal или Firebird Embedded сложно переносить?
Да гораздо проще.

← →
DenK_vrtz © (2004-06-01 10:25) [12]

>Alexandr (01.06.04 10:15) [9]
>я еще с ДВК начинал

разговор про СУБД, а не про тип ПК

>Назовите хоть один аргумент в пользу парадокса по сравнению с клиент-серверными СУБД

обсуждать данный вопрос в рамках данного топика не имеет никакого смысла

А у вас, я замечу, тоже не всегда все гладко, так что давайте не будем

← →
Alexandr (2004-06-01 10:28) [13]

>
> А у вас, я замечу, тоже не всегда все гладко, так что давайте
> не будем

да, давайте не будем про то, у кого где гладко.
И обсуждать вопрос про выбор СУБД не будем.
пусть учатся на своих ошибках.

← →
app © (2004-06-01 10:29) [14]

если есть желание повоевать то заведите тему: что то против чего то.

← →
Alexandr (2004-06-01 10:31) [15]

не... упаси бог воевать. Ради чего?

вы бы хоть назвали то, на что присели .
я про субд.

Спектр используемых баз очень широк.

>я про субд

Круг довольно обширен - от Firebird, MSSQL Server, DB2, Sybase до Oracle. Это наиболее распространенные. Есть и другие.

← →
bn2 (2004-06-01 18:35) [19]

Самый правильный способ - это использовать вспомогательную таблицу, где будут хранится текущие значения счётчиков для разных таблиц. Способ этот применяется в большинстве СУБД, только выглядит он как тригер+секвенс (Оракл, Интербейз). Случаев, когда нужно при добавлении знать будущий ключ записи - больше чем достаточно при более-менее серьёзной задаче.

ЗЫ. Даже сейчас есть большой смысл применять Парадок. Первый из них - переносимость приложения, особенно есть используется не БДЕ, а визуальные компоненты, напрямую работающие с базой.

← →
vlad-mal (2004-06-01 19:18) [20]

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

Назови хотя бы один способ, кроме BDE, в которм поддерживаются все типы данных при чтении и можно не только читать, но и писать.

Нет таких! Если только сам Paradox... (но и он, кажется, BDE юзает?)

← →
bn2 (2004-06-02 09:50) [21]

Барт Симпсон написал: "I will use Google before asking dumb questions". Например, на torry.ru куча ответов...
Насчёт "всех типов данных" - совершества нет. Всегда есть условия, которые надо учитывать. И всегда есть выбор между н-мегабайт БДЕ и отсуствием "супер-пупер типа данных".

ЗЫ. В MySQL вообще много чего нет (проще перечислить, что есть) - а куча народу использует. В Парадоксе хоть форинг-кей есть....

В DB2 есть такой механизм.
Заводим уникальное поле как CHARACTER(13) FOR BIT DATA
И пользуемся функцией GENERATE_UNIQUE(), которая всегда возвращает уникальное значение.

В приложение кладем qrUnique: TQuery
SELECT NUM.NUM
FROM (VALUES(GENERATE_UNIQUE())) AS NUM(NUM)

Оформляем:
function Tdm.GenerateUnique: Variant;
begin
Self.qrUnique.Open;
Result:= Self.qrUniqueNUM.Value;
Self.qrUnique.Close
end;

И на нужном DataSet"е пишем:
procedure TForm1.Query1NewRecord(DataSet: TDataSet);
begin
DataSet.FieldByName("ID").AsVariant:= dm.GenerateUnique
end

Минусы только в отсутствии привычного INTEGER и немного большим размером поля.

эмуляция поля autoinc Найти похожие ветки