Autor Téma: Problém s TDate(time) u klientské konzole běžící přes VPN proti MS SQL  (Přečteno 8700 krát)

Offline < z >

  • Administrátoři
  • Guru
  • *****
  • Příspěvků: 1174
  • Karma: 44
    • Verze Delphi: 7, 2010
nevim, jestli to chapu dobre, ale pokud pouzivas INSERT ... 'YYYY/MM/DD', tak je mozne ze ti server MM a DD prohodi,
proto ti vznika ten problem, ne? a kdyz misto toho pouzijes YYYYMMDD, to nende?

ale pokud jsem dostatecne nepochopil problem, tak pardon :)

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 3339
  • Karma: 139
    • Verze Delphi: D2007, XE3, DX10
MMCH pro pf1957 - to je ročník? V tom případě jsem hodně těsně před tebou  ;)
Jo, fotka je autenticka.

Offline vladyk

  • Příspěvků: 32
  • Karma: 0
nevim, jestli to chapu dobre, ale pokud pouzivas INSERT ... 'YYYY/MM/DD', tak je mozne ze ti server MM a DD prohodi,
proto ti vznika ten problem, ne? a kdyz misto toho pouzijes YYYYMMDD, to nende?

ale pokud jsem dostatecne nepochopil problem, tak pardon :)

V poho, spíš bych se měl omlouvat já, že jsem tak vyjel, holt starej prudivej dědek :-D

Problém je v tom, že on to prohazuje (při přístupu via VPN a/nebo RDC) bez ohledu na to, jakej tvar na vstupu zrovna je - prostě to zmrší - a jen někdy.

Tak jsem vzdal pokusy pochopit proč (neb to byl samý cimrmanovský frustrační postup - prvek očekávání, prvek zklamání...), na začátku při nastavování výchozích parametrů si testnu, jestli mi to náhodou neotáčí a když jo, tak jak, a už mu to pak lstivě předem strkám tak, aby to otáčel do správné podoby. Moc vědecký to asi není, ale funguje to...

...akorát mi teď došlo, že občas píšu i do cizích databází... tak to si budu muset testovat i ty... no, pořád to ještě není tak hrozný :-)

Offline < z >

  • Administrátoři
  • Guru
  • *****
  • Příspěvků: 1174
  • Karma: 44
    • Verze Delphi: 7, 2010
ale tim nezodpovidas, jestli se to pouzitim YYYYMMDD nevyresi, protoze to je ISO format a to si jen tak prece nemuze prehazovat ;)

nevim sice, jak zjistujes, jestli to prehazuje, ale mozna bude jednodussi pouzit neco odtud na zjisteni aktualniho formatu
http://social.msdn.microsoft.com/Forums/en/transactsql/thread/a755c315-ea46-4f87-9ddf-07259c4ef8f1

Offline vladyk

  • Příspěvků: 32
  • Karma: 0
Neodpovídám, protože musím do rána něco dopsat a ještě bych rád hodil očko na fotbal :-)

YYYYMMDD funguje. Jenže já to stejně musím hnát přes ty funkce, protože uživatel chce vidět formát, na který je zvyklý, a pak už je jedno, jestli někam doplňuju nuly, pomlčky nebo lomítka (jak to mám doteď, tak to buď sežere US, nebo ODBC - problém nebyl v konvertzi jako takové, ale v tom, že jsem netušil, že ji potřebuju).

Ale já zas decentně připomenu tu původní otázku, o kterou jde mně: PROČ se to sakra přehazuje? :-)


Offline vladyk

  • Příspěvků: 32
  • Karma: 0
MMCH dá se v YYYYMMDD podstrčit MS SQL 2000vce tak časový údaj?

Offline vladyk

  • Příspěvků: 32
  • Karma: 0
...taky... měl jsem náročnou noc a klapu na netypisch klávesnici :-)

Offline < z >

  • Administrátoři
  • Guru
  • *****
  • Příspěvků: 1174
  • Karma: 44
    • Verze Delphi: 7, 2010
chtelo by to taky trochu samostatnosti a googlu :)

melo by fungovat
YYYYMMDD[ HH:NN:SS[.ZZZ]]

jinak jsem se docetl, ze pri jakemkoliv dotazu by se misto prosteho stringu s datumem melo pouzivat CONVERT na datum,
ono si to samo sezere lokalni format a predela ho na spravny format sql serveru - tim by mely odpadnout ty funkce na zjistovani a ta
... s tim, ze kdyz nekdo pouziva prosty string, tak si primo zadelava na tyto problemy ;)

Offline vladyk

  • Příspěvků: 32
  • Karma: 0
Jen si rejpni, máš nárok :-)

Strejda Gůgl mi sice něco málo podstrčil, ale nijak extra to nefungovalo ("T" jako oddělovač), dvojtečku jsem nikde nepotkal, asi jsem se blbě ptal, a samotnýho mne nenapadla. Dííííky.

CONVERT ani CAST právě na 2000 moc nefungoval, proto jsem si napsal svoje vlastní funkce, který fungovaly. A až do letoška nebyl důvod je měnit... njn, všechno jednou skončí.