Плять. Это не лечится. Наших программеров поймали на том, что в базу идут запросы типа select * from blabla where [primary_key] is NULL

(с) БОР

Здравствуйте, int13h, Вы писали:

I>

I>Плять. Это не лечится. Наших программеров поймали на том, что в базу идут запросы типа select * from blabla where [primary_key] is NULL

I>(с) БОР

Здравствуйте, gwg-605, Вы писали:

G6>Здравствуйте, int13h, Вы писали:

I>>

I>>Плять. Это не лечится. Наших программеров поймали на том, что в базу идут запросы типа select * from blabla where [primary_key] is NULL

I>>(с) БОР

Primary Key не может иметь значение NULL. По-определению. Либо фиктивная история попала на БОР, либо программеры... м-м-м... "никакие"...

Здравствуйте, maxluzin, Вы писали:

M>Здравствуйте, gwg-605, Вы писали:

G6>>Здравствуйте, int13h, Вы писали:

I>>>

I>>>Плять. Это не лечится. Наших программеров поймали на том, что в базу идут запросы типа select * from blabla where [primary_key] is NULL

I>>>(с) БОР

M>Primary Key не может иметь значение NULL. По-определению. Либо фиктивная история попала на БОР, либо программеры... м-м-м... "никакие"...

Хотя, я тут подумал, если есть какой-то промежуточный layer или адаптер по генерации SQL-кода запросов на основе каких-то внешних параметров, то автоматическая генерация таких команд вполне возможна. Там же написано: "в базу идут запросы", а не "в исходном тексте присутствуют команды". Может какие-то логи аудитора БД анализировали... Хотя, такой адаптер тоже не совсем доделанный, не анализирует всё до конца...

M>>Primary Key не может иметь значение NULL. По-определению. Либо фиктивная история попала на БОР, либо программеры... м-м-м... "никакие"...

M>Хотя, я тут подумал, если есть какой-то промежуточный layer или адаптер по генерации SQL-кода запросов на основе каких-то внешних параметров, то автоматическая генерация таких команд вполне возможна. Там же написано: "в базу идут запросы", а не "в исходном тексте присутствуют команды". Может какие-то логи аудитора БД анализировали... Хотя, такой адаптер тоже не совсем доделанный, не анализирует всё до конца...

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

Здравствуйте, int13h, Вы писали:

I>

I>Плять. Это не лечится. Наших программеров поймали на том, что в базу идут запросы типа select * from blabla where [primary_key] is NULL

I>(с) БОР

Не зачет!
Если в blabla есть outer join или вьюха с ним же, то вполне нормальная ситуация.
По одной приведенной строке НИЧЕГО нельзя сказать о качестве кода.

Здравствуйте, gwg-605, Вы писали:

M>>>Primary Key не может иметь значение NULL. По-определению. Либо фиктивная история попала на БОР, либо программеры... м-м-м... "никакие"...

M>>Хотя, я тут подумал, если есть какой-то промежуточный layer или адаптер по генерации SQL-кода запросов на основе каких-то внешних параметров, то автоматическая генерация таких команд вполне возможна. Там же написано: "в базу идут запросы", а не "в исходном тексте присутствуют команды". Может какие-то логи аудитора БД анализировали... Хотя, такой адаптер тоже не совсем доделанный, не анализирует всё до конца...

G6>просто для ADODB это стандартный паттерн когда надо добавить новую запись. В возвращаемом рекордсете получишь всю необходимую инфу о филдах и т.п.

А если включить SQL Trace со стороны БД и проанализировать именно SQL-команды, то что увидишь?... Вот-вот... ADODB — просто надстройка. И не самая последняя перед БД. А, судя по тексту, анализировали именно логи БД.

З.Ы. Ну да ладно. Хрен с этим! Чего гадать над кофейной гущей, как там было на самом деле...

Здравствуйте, gwg-605, Вы писали:

G6>просто для ADODB это стандартный паттерн когда надо добавить новую запись. В возвращаемом рекордсете получишь всю необходимую инфу о филдах и т.п.

С этим не работал: не моя специализация

Здравствуйте, int13h, Вы писали:

I>

I>Плять. Это не лечится. Наших программеров поймали на том, что в базу идут запросы типа select * from blabla where [primary_key] is NULL

I>(с) БОР

И что? Видно нужен пустой набор со структурой таблицы.
Например, про меня бы написали "поймали программера, у которого запрос с where 1=0" .

Здравствуйте, maxluzin, Вы писали:

M>Primary Key не может иметь значение NULL. По-определению. Либо фиктивная история попала на БОР, либо программеры... м-м-м... "никакие"...

Может В одной из версий FB был такой баг, когда при развертывании бакэпа мог произойти сбой и primary key вполне так себе NULL.

Второй вариант с тем же FB. Ручками отключаем триггер check_XXXX (где XXX порядковый номер) который отвечает за not null. Потом меняем что угодно на null и включаем его обратно.

А еще в какой-то версии того же FB была возможность создать primary key на null столбец. Так как null по определению не равен другому null вполне так запросто создавались primary key со значением null.

P.S. С тех самых пор всегда пишу для FB Тригер на before insert для кажой таблички
if (new.primary_key is null) then new.primary_key = gen_id(gen, 1);


Раньше еще писал на before update для запрета изменения primary key.

Здравствуйте, gwg-605, Вы писали:

G6>просто для ADODB это стандартный паттерн когда надо добавить новую запись. В возвращаемом рекордсете получишь всю необходимую инфу о филдах и т.п.

Можно

where 0 = 1

Здравствуйте, Skleroz, Вы писали:

S>Здравствуйте, gwg-605, Вы писали:

G6>>просто для ADODB это стандартный паттерн когда надо добавить новую запись. В возвращаемом рекордсете получишь всю необходимую инфу о филдах и т.п.

S>Можно

where 0 = 1

where 0

на мускуле работает

Здравствуйте, int13h, Вы писали:

S>>Можно

where 0 = 1

I>

where 0

I>на мускуле работает

Ну мало ли что там работает.

На MSSQL, ib/fb и кажись оракле — не сработает.

PS. И кстати, тут уже говорили что у ib вполне себе может быть и PKey=NULL . Так что — раз на раз.... А 1=0 — гарантированно false даст, не зависимо от заморочек конкретного сервака.