Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2006.12.17;
Скачать: CL | DM;

Вниз

Формат даты в 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]
> отвечаю про конфликт: при вставке новой записи если беру
> значение генератора до вставки, тогда при неудачной вставке
> засада -  ниспользованое значение, не фатально, но всеже
> неприятно,


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


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


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


 
Rule ©   (2006-10-09 16:45) [29]

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


 
Rule ©   (2006-10-09 16:46) [30]

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


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


 
Johnmen ©   (2006-10-09 16:49) [31]


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


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


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

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


 
Rule ©   (2006-10-09 16:56) [33]

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


 
Rule ©   (2006-10-09 16:58) [34]

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


 
Rule ©   (2006-10-09 16:59) [35]

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


 
Rule ©   (2006-10-09 17:00) [36]

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


 
Johnmen ©   (2006-10-09 17:02) [37]


> Rule ©   (09.10.06 16:56) [33]


Нет, ты всё же скажи, чем так характерна хранимка в трудной борьбе с дырками.


 
Rule ©   (2006-10-09 17:06) [38]

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


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


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


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


 
Rule ©   (2006-10-09 17:20) [40]

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



Страницы: 1 2 вся ветка

Текущий архив: 2006.12.17;
Скачать: CL | DM;

Наверх




Память: 0.57 MB
Время: 0.049 c
2-1164719095
Феникс
2006-11-28 16:04
2006.12.17
Не могу разобраться с ExtractFilePath(Application.ExeName)


2-1164868094
pavel_guzhanov
2006-11-30 09:28
2006.12.17
Работа с XML


3-1160382157
O.O
2006-10-09 12:22
2006.12.17
Формат даты в FireBird


9-1140205350
ZeFiR
2006-02-17 22:42
2006.12.17
вопрос по... змейке)))


1-1162296274
GEN++
2006-10-31 15:04
2006.12.17
Сжатие рисунка