Формат даты в FireBird

← →
O.O (2006-10-09 12:22) [0]

Зависит ли формат Даты в SQL запросе от системных настроек Windows или он всегда должен писаться через точку, и как тогда правильно dd.mm.yyyy или mm.dd.yyyy

← →
Desdechado © (2006-10-09 12:31) [1]

правильно - через параметры, для которых формат не имеет значения, ибо используется внетреннее представление TDateTime

← →
Sergey13 © (2006-10-09 13:04) [2]

> [1] Desdechado © (09.10.06 12:31)
> правильно - через параметры

Я бы добавил "правильного типа". А то и через строковые можно. 8-)

← →
O.O (2006-10-09 13:05) [3]

Правильно ли понимаю?
В таблице 10 различных полей
Мне нужно добавлять записи с внесением данных в три поля:

-ключ
-ФИО
-ДАТА

Добавляю в TIBQuery.Params 3 параметра А,B,C
A - тип ftInteger
B - тип ftString
С - тип ftDate
затем так
Q.SQL.Append("INSERT INTO Table (ID_Field, FIO, DATE) VALUES(:A, :B, :C)"); Q.ParamByName("A").AsInteger := StrToInt(Edit1.Text); Q.ParamByName("B").AsString := Edit2.Text; Q.ParamByName("C").AsDateTime := DateTimePicker1.Date; Q.Open;
или подругому ?

← →
Sergey13 © (2006-10-09 13:08) [4]

> [3] O.O (09.10.06 13:05)

Идея про параметры воспринята правильно, что можно было бы и самому проверить.
А вот за
Q.ParamByName("A").AsInteger := StrToInt(Edit1.Text);
если это то, о чем я подумал, надо руки отрывать. 8-)

← →
O.O (2006-10-09 13:24) [5]

Скажи как правильно и я сам их себе оторву :)

← →
Sergey13 © (2006-10-09 13:30) [6]

> [5] O.O (09.10.06 13:24)

Если ID_Field - это поле ПЕВИЧНОГО КЛЮЧА (судя по названию это так и есть) то значения в него руками не вносят (за очень редким исключением, оговорюсь что бы не поднимать вечный спор 8-). Для этого в FireBird есть генераторы, значения которых записывают в таблице тригерами.

← →
Sergey13 © (2006-10-09 13:32) [7]

> [5] O.O (09.10.06 13:24)

http://www.ibase.ru/devinfo/generator.htm
И остальное смотри - там много полезного.

← →
atruhin © (2006-10-09 13:36) [8]

> Если ID_Field - это поле ПЕВИЧНОГО КЛЮЧА (судя по названию
> это так и есть) то значения в него руками не вносят

Ну почему не вносят? Запрашивают генератор и вносят. Нормальный стиль работы с ФБ.

> [3] O.O (09.10.06 13:05)

Это не правильно. Примерно так:
Q.SQL.Text := "....";
Q.Prepare;
Q.ParamByName().As...
Q.Exec....
Если очень нужно без параметров, то FB принимает дату, не зависимо от локали, в формате: yyyy.mm.dd

← →
O.O (2006-10-09 13:40) [9]

Спасибо всем за помощь

← →
Sergey13 © (2006-10-09 13:46) [10]

> [8] atruhin © (09.10.06 13:36)
> Ну почему не вносят? Запрашивают генератор и вносят. Нормальный
> стиль работы с ФБ.
А запрашивают по телефону, что бы руками ввести? 8-)

← →
O.O (2006-10-09 14:01) [11]

Ребяты, я там просто для примера привёл чё в голову взбрело. Конечно-же поле первичного ключа заполняю используя генератор.

← →
Rule © (2006-10-09 14:03) [12]

atruhin © (09.10.06 13:36) [8]
Ну почему не вносят? Запрашивают генератор и вносят. Нормальный стиль работы с ФБ.

ссылку на первоисточник ... или ты у нас законодатель формата ?
ответь на вопрос тогда: зачем это делать ??? зачем запрашивать значение генератора а потом вносить изменения ???, а как же тогда многопользовательность и конфликты ???

← →
O.O (2006-10-09 14:33) [13]

К примеру делаю новую запись в таблице А и таблице Б, и есть необходимость чтоб в поле первичного ключа обеих таблиц было одно и тоже значение. Такое вполне может быть. Получаем одно значение генератора и заполняем поле ключа в обеих таблицах. Если в добавок к этому во всех таблицах базы используется один и тот-же генератор, то на мой взгляд никаких конфликтов быть не может.

← →
_RusLAN © (2006-10-09 14:58) [14]

> во всех таблицах базы используется один и тот-же генератор

а это еще зачем????

← →
O.O (2006-10-09 15:02) [15]

А почему нет?
Абсолютная атомарность всех записей в базе данных

← →
O.O (2006-10-09 15:09) [16]

Ещё если у всех таблиц поле первичного кода одинаково называется так вообще красота.

← →
O.O (2006-10-09 15:10) [17]

Первичного ключа, очепятка :)

← →
Rule © (2006-10-09 15:55) [18]

O.O (09.10.06 14:33) [13]
примеру делаю новую запись в таблице А и таблице Б, и есть необходимость чтоб в поле первичного ключа обеих таблиц было одно и тоже значение.

зачем ????

← →
Sergey13 © (2006-10-09 16:00) [19]

> [18] Rule © (09.10.06 15:55)

А что? При связи 1:1 очень удобно. И ПК и ВК одновременно.

← →
Rule © (2006-10-09 16:02) [20]

Sergey13 © (09.10.06 16:00) [19]
а не проще тогда записи вставлять с помощью хранимки, как это делают мелкомягкие ...

← →
Rule © (2006-10-09 16:03) [21]

или регулировать этот вопрос внутри базы, ибо уверен что конфликты при мультиюзерстве неизбежны ...

← →
Sergey13 © (2006-10-09 16:12) [22]

> [20] Rule © (09.10.06 16:02)
Проще чем что? Лично я например не сторонник писать на всё и вся хранимки, ибо смысла особого не вижу.

> [21] Rule © (09.10.06 16:03)
А какие тут могут быть конфликты?

← →
Konrads (2006-10-09 16:15) [23]

Была бы возможность, а её использование нет-нет да и пригодится :)
А какие конфликты в мультиюзерстве? Откуда им взятся? Какой природы может возникнуть конфликт?

← →
Konrads (2006-10-09 16:17) [24]

Sergey13 одновременно практически :)

← →
Rule © (2006-10-09 16:21) [25]

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

← →
Konrads (2006-10-09 16:22) [26]

тоже значение взять невозможно

← →
Sergey13 © (2006-10-09 16:41) [27]

> [25] Rule © (09.10.06 16:21)
Ну дыры в ИД обсуждать не будем, надоело. 8-)

> если в процессе вставки, то не известно сколько будет вставляться
> запись и может оказаться что в этот момент тоже самое значение
> взял кто-то другой и тогда будет дублирование
А откуда дублирование то?
1. :ID = Select Gen_Id(Gen,1) from RDB$DATABASE
2. Insert into table1(id) values(:ID)
3. Insert into table2(id) values(:ID)

← →
Johnmen © (2006-10-09 16:44) [28]

> Rule © (09.10.06 15:55) [18]
> O.O (09.10.06 14:33) [13] примеру делаю новую запись в
> таблице А и таблице Б, и есть необходимость чтоб в поле
> первичного ключа обеих таблиц было одно и тоже значение.
> зачем ????

В две таблицы - Мастерную и Детальную.

> Rule © (09.10.06 16:21) [25]
> отвечаю про конфликт: при вставке новой записи если беру
> значение генератора до вставки, тогда при неудачной вставке
> засада - ниспользованое значение, не фатально, но всеже
> неприятно,

Кому неприятно? Серверу? :)

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

Так никто не делает. Разве что совсем новички...

Sergey13 © (09.10.06 16:41) [27]
бац а запись не может быть вставлена, и все дырка ... ничего страшного, повторяюсь, но неприятно

лана, поддерживаю:
Sergey13 © (09.10.06 16:41) [27]
Ну дыры в ИД обсуждать не будем, надоело. 8-)

закрываю тему ...но помоему проще в хранимку засунуть, хотя дело вкуса ...

> Rule © (09.10.06 16:46) [30]
> ...но помоему проще в хранимку засунуть, хотя дело вкуса

Чем хранимка спасёт пламенного борца с дырками?
:)))

← →
Konrads (2006-10-09 16:54) [32]

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

Johnmen © (09.10.06 16:49) [31]
тем, что если в хранимку передались правильные параметры, то уже уменьшаются шансы на ошибку вставки, плюс валидацию можно засунуть в саму хранимку, в итоге генерировать новое значение гениратора только при прохождении такой валидации, причем разгружая бизнес-логику клиента ...

Konrads (09.10.06 16:54) [32]
есть случаи когда "дырки" могут усложнить ошибку анализа ... допустим у нас есть какая-либо таблица, в которую только вставляются данные, а потом используются только для чтения ... часто встречается такая ситуация ... так вот по "дыркам" можно отслеживать где был косяк при вставке, вычислить проблеммные участки, тоесть определить что была какая-то ошибка в работе системы и опираясь на это найти этот косяк ...

Konrads (09.10.06 16:54) [32]
и чем интенсивнее идет вставка данных и чем больше пользователей это делают, плюс добавить репликацию ... тогда становиться ощутимо

Konrads (09.10.06 16:54) [32]
учитывая то, что обычно ошибки в таких таблицах обнаруживаются в конце анализа и закрытия какого-либо периода, в таком случае искать ошибку во всем периоде в большом количестве записей тяжело ...

Johnmen © (09.10.06 17:02) [37]
можно в ней провести валидацию, а если используется совместный код, то упрощает взаимопонимание между разработчиками ...

← →
Konrads (2006-10-09 17:18) [39]

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

Если чесно, но лично моё мнение такое:
Делать сколь-либо серьёзный анализ на основе того что появилась "дырка" в таблице в которую толко записываются данные, а поле первичного ключа заполняется триггером от своего собственного генератора - равносильно поиску чёрной кошки в тёмной комнате когда её там нет. Для анализа на мой взгляд надо пользоваться более точными инструментами.

Konrads (09.10.06 17:18) [39]
нууууууууууууууу, как сказать .... может ты и прав, но мне лично было удобнее искать дырки, в 90 процентах "дырки" указывали на косяк ...

Формат даты в FireBird Найти похожие ветки