Дати в Парадокс SQL

Дати в Парадокс SQL

Как да форматирам датата в текста на SQL завявка и какви проблеми с регионал сетинга на различни компютри могат да възникнат?

Искам да трия всички записи с дата между две дати (Timestamp).
В SQL explorer-a датите са във формата от регионал сетинга, но в DBD са HH.NN.SS YYYY.MM.DD

Най-хубаво ще е, ако мога да запиша в заявката направо real стойнстта на tDateTime:

delete from Jrn_SourceProfilaktika where DtTm<37252.876

но дори и съвсем хубава дата (ISO 8601 :) не желае да я приеме:
delete from Jrn_SourceProfilaktika where DtTm<'2005.02.01 10:11:12'

ПП
Иначе: само с параметри:

{}function Table_DataDelete_DtTm1( const aDataBaseName, aTableName, aWhere1Side: String; aDtTm: tDateTime): integer;

    var

      aQuery: tQuery;

      s: string;

    begin

      aQuery:=tQuery.Create(nil);

      try

        aQuery.DataBaseName:=aDataBaseName;

        aQuery.SQL.Text := 'delete from '+aTableName+cCrLf+

                           'where '+aWhere1Side+':xDtTm'+cCrLf;

        aQuery.ParamByName('xDtTm').AsDateTime := aDtTm;

        aQuery.ExecSQL;

        Result:=aQuery.RowsAffected;

      finally

        FreeAndNil(aQuery);

      end;

    end;

Че то с параметри си е "официалния" начин :)
Какво имаш против тях?

:) ами почти нищо :), но не ми е приятно, че не мога да напиша един "чист" SQL и да си го изпълня.
Някъде ми се губи една от старите книжки за тоя диалект на SQL.
В тая, която намерих - "Тайните на Делфи" има доста за форматите на BDE, ама трябва да изпълня няколко функции, докато стигна рънтайм до истината.
Предполагам, че ако тръгна да дебъгвам, все някъде ще видя как Борланд си го правят от параметъра.

'2006-04-20 13:17:54'
Това е timestamp формата в SQL92. Local SQL май беше подмножество на SQL92.

А,а.., чертичките :)
Стана.
Благодаря !

Ама тая заявка не успях да я накярам да тръгне:

Insert into Jrn_Source 

(IdSource,IdProg,DtTm,DtTmB,Tip)

 Values

('2','2','2006-04-21 01:07:16','2006-04-22 15:00:00','0')

SQL Explorera казва: "Type mismatch in expression."
Вярно определя броя на параметрите (ако не съвпада се оплаква друго).
Ако няма дати - също работи.

DtTm и DtTmB са си TIMESTAMP

А ето ти и още две "парадоксални" недоразумения:

1. select * from orders where shipdate > cast('1994-04-01 12:00' as timestamp);
Това чудо минава без exception, но връща всички редове от таблицата?!?!

2. select cast('1994-04-01 12:00' as timestamp) from orders;
Това пък гърми с exception "'0.0' is not valid timestamp"

Надявах се, че поне cast() би трябвало да реши проблема. Опитах се да помогна, ама май само мога да ти съчувствам за взаимоотношенията ти с Парадокс...

Ето я и истината (май):

There are two acceptable formats for the date parts of DATE and TIMESTAMP literals in local SQL statements: the US date format and the European date format. Which one of the two you use is predicated on the Windows configuration settings for Date Separator and Short Date Style. If the Date Separator is a slash (/) and Short Date Style puts the month before the day (such as MM-dd-yy), the date must be in a US date format, MM/DD/YY or MM/DD/YYYY. If the Date Separator is a period (.) and Short Date Style puts the day before the month (such as dd.MM.yy), the date must be in a European date format, DD.MM.YY or DD.MM.YYYY. A combination of Short Date Style of month before day and a Date Separator of anything but a period is not supported in local SQL. DATE and TIMESTAMP values passed to an SQL statement via parameters and the values in columns are unaffected by these restrictions on format. Only literal values are affected.

To prevent date literals from being mistaken by the SQL parser for arithmetic calculations, enclose them in quotation marks. This keeps 1/23/1998 from being mistaken for 1 divided by 23 divided by 1998.

Example of a date literal in a US format:

SELECT *

FROM Orders

WHERE (SaleDate <= "1/23/1998")

Example of the same date literal in a European format:

SELECT *

FROM Orders

WHERE (SaleDate <= "23.1.1998")

Leading zeros for the month and day fields are optional.

If the century is not specified for the year in a date value, the BDE settings FOURDIGITYEAR and YEARBIASED control the century of the date.

Благодаря, днес до обяд се борих с тая история (то вече стана вчера :))
Накрая се оправих (с параметри пак).
Обаче излезе някакъв друг SQL проблем с един шортинт, но го заобиколих по най-бързия начин и, да се надяваме, за дълго време съм приключил с Парадокса.

Хубаво е, че проблемът с датите май се изясни, но с тоя смотан serch на dir.bg - кой ли ще успее да го ползва.

Въпросът с датите, в частност техният формат, при работа е проблематичен при всички бази с данни. Имам впредвид най вече търсене и филтър, а понякога и при запис.

Има едно практическо решение на въпроса, неприятно свързано с преписване на програмата и преправяне на базата с данни. Просто направи датите, отделно часа, поле от тип Integer. В програмата конвертирай данните при четене и записване от Integer в дата и обратно.

виж следните примери:
1. филтър: DataSet.Filter='<датно поле> >='+IntToStr(d)+' and <датно поле> <='+IntToStr(d);
2. или търсене: DataSet.Locate(<датно поле>, d, []);
където d е конвертираната стойност на датата в число.

Въпреки многото работа, която трябва да се свърши има и някои други предимства: не зависите от системния (Windows) формат на датата, да не говорим при записване на дата чрез SQL заявка.

Това е само едно предложение, което има едно практическо предимство: сигурност и надежност при работа.

Хе, хе, мислим еднакво :)

В мойте проекти много рядко ползвам формати за дати в базите данни, обикновенно ползвам или секунди или дни, напред/назад от определени дати, съвпадащи с Борланд или с Юникс.

Обаче, за някаква мизерна табличка, преди години, съм направил изключение и днес ми се връща.
А тъй като и аз се правя на хитър (като теб :) и не ми се е налагало да се сблъсквам до сега с проблемите с датите, затова се замотах.
Но вече това е история.

Впрочем, в клуб "Бази данни" си обичат датите и могат да правят с тях всичко.