A little help ...
24 отговора
394 прегледа
A little help ...
Здравейте! Ще ми се пак да попитам за нещичко, което е следното:
значи имам си една прекрасна базичка на SQL-а. Правя си едно куири от типа
select вземи_всичко
from там_и_там
where така_и_така
където условието ми е datastart = 'датата',
и сервера пищи : не може така два разлини типа данни - datetime i varchar. Ок от моя страна и му праскам едно Convert(datatype(lenght), expression, format). Аз лично ползвам формат 111. Хареса му. Обаче нищо не ми връща, т.е връща ми 0 rows. А би трябвало да ми върне повече от 2 rows. Някаква идея. Явно че converta нещо го бъркам.
Мерси предварително...
значи имам си една прекрасна базичка на SQL-а. Правя си едно куири от типа
select вземи_всичко
from там_и_там
where така_и_така
където условието ми е datastart = 'датата',
и сервера пищи : не може така два разлини типа данни - datetime i varchar. Ок от моя страна и му праскам едно Convert(datatype(lenght), expression, format). Аз лично ползвам формат 111. Хареса му. Обаче нищо не ми връща, т.е връща ми 0 rows. А би трябвало да ми върне повече от 2 rows. Някаква идея. Явно че converta нещо го бъркам.
Мерси предварително...
Отг: A little help ...
ami kaji kakwa ti e bazichkata, shtoto naj-shibanoto neshto w bazite e tipa DATE(ili tam w sichkite mu izdihaniq)
ama obiknoweno kato napishesh data ot wida
'25-APR-1978' shte trygne
pyk i wnimawaj w izpolzwaneto na ' i "
ako ne stane kaji za kakwa baza stawa wypros i za kakyw ezik (t.e. SQL ili embedded SQL w ezik za programirane)
ama obiknoweno kato napishesh data ot wida
'25-APR-1978' shte trygne
pyk i wnimawaj w izpolzwaneto na ' i "
ako ne stane kaji za kakwa baza stawa wypros i za kakyw ezik (t.e. SQL ili embedded SQL w ezik za programirane)
Следната заявка
SELECT * FROM MYTABLE WHERE MYDATE = '8/28/00'
При мен си върви.
Да не би настройката на някой от дриверите да не е добра и драйвера да конвертира датата до нещо друго?
С ODBC ли си? Нали си на MSSQL - опитай в Enterprise manager.
Последната идея - пусни trace на SQL сървера и виж каква точно заявка пращаш.
При мен си върви.
Да не би настройката на някой от дриверите да не е добра и драйвера да конвертира датата до нещо друго?
С ODBC ли си? Нали си на MSSQL - опитай в Enterprise manager.
Последната идея - пусни trace на SQL сървера и виж каква точно заявка пращаш.
Отг: Следната заявка
Да с ODBC съм. Пуснах го сто пъти на Query Analyzer и пак не ми връща резултат. Хм, трябваше да спомена че Mydata е от типа datatime datatype. Базата ми е на SQL сервера. Пусках го и така както е предложението, но упорито ми връща резултат 0 rows, което не е вярно.
Хм,
Идея първа: опитай следния формат '1/24/00', после '24/1/00'. разбира се вкарай валидни записи.
Втора: - какво ти дава SQL trace?
И моята дата беше datetime type
Втора: - какво ти дава SQL trace?
И моята дата беше datetime type
Отг: Хм,
разбира се че го пускам с валидни данни. И така и онака и все ми връща 0 реда. Второ ако му задам
mydata = '../../..' типраска грешка, от типа "ало къде така два различни типа данни", за това използвам convert.
mydata = '../../..' типраска грешка, от типа "ало къде така два различни типа данни", за това използвам convert.
ако някой се интересува...
проблема е в не съвсем точно използване на convert-функцията. в общи линии, 111 се използва, ако format-a е yyyy/mm/dd, а 11 - ако format-а е yy/mm/dd. усещате ли разликата? ми да, сигурно няма записи от 0099 година :).
четете бе хора - то си го пише в books online (е и аз не се усетих веднага ;), признавам си)
четете бе хора - то си го пише в books online (е и аз не се усетих веднага ;), признавам си)
Веселина,
Това ли беше проблема? :-)
Затова ти казах пусни trace-to :-).
Надявам се да нямаш проблем вече :-)
Затова ти казах пусни trace-to :-).
Надявам се да нямаш проблем вече :-)
Отг: Веселина,
Жоро не съвсем, не това баш проблема. Защото ис формат 11 демек гг/мм/дд, пак връща 0 ред, демек пак нчма данни. Та целия номер е в това че трябва да му дам и часа и минутите. Т.е в базата даните в datetime са ми записани барабар с часа (то това ми требе де) и когато му задам условието върни ми всичко за дадената дата (без часа) ми връща 0 реда, когато му задам датата + часа си заспива идеално. Та според мен те това ми беше "спъни камука".
мерси на всички ... (и май до скоро, хихи)..
мерси на всички ... (и май до скоро, хихи)..
да,
обаче и да беше се сетила за часовете в датата, със 111 нямаше да тръгне ;)
и, Жоро, съмнявам се, че trace щеше да помогне - специално за случая. абе въобще, вършел ли ти е работа за нещо друго, освен за статистика(брой повиквания, скорост, натоварвания, колко пъти прави еди-кво си)?
и, Жоро, съмнявам се, че trace щеше да помогне - специално за случая. абе въобще, вършел ли ти е работа за нещо друго, освен за статистика(брой повиквания, скорост, натоварвания, колко пъти прави еди-кво си)?
Отг: да,
Да бе, така е. Имам в предвид за 11 и 111. Съгласна съм, че ми помогна. И много, много мерси .И даже и черпня ще има, както се разбрахме.
Отг: да,
и пържени картофи! иначе ник'ва помощ повече! и крем карамел! и шкембе чорба. нещо тарифа за услуги да съм окачил някъде? ясен ми е(горе-долу) тоя сървър, обаждам се... човек да не те бъзикне на професионална тема... тва, младото поколение, сте много докачливи бе ;) айде, че ме юркат...
Отг: да,
Бре а наливната бира къде я забрави? Че тя е основен елемент в черпнята, primary key така да се каже.
Отг: A little help ...
Abe pichowe CHETETE HELPOWE BE!!!
"To search for a partial date or time value, use the LIKE operator. SQL Server first converts the dates to datetime format and then to varchar..."
"To search for a partial date or time value, use the LIKE operator. SQL Server first converts the dates to datetime format and then to varchar..."
къде го чете пък това?
щото на някакво научно-популярно четиво ми прилича ;). без да се обиждаш, май не си подбрал точния цитат, или поне не целия - в какъв вид е датата, като се превърне до varchar? и ако пишеш нещо, дето се очаква да надживее текущата версия на SQL Server-a, не би ли сложил все пак един convert, ей така, за всеки случай, да не би M$ да реши в някоя следваща версия да смени вида на датата, имплицитно конвертирана до varchar?
Отг: къде го чете пък това?
да бе кажи къде го чете, щото сума ти хелпове изчетох, барабар с една тухла 1200 стр. SQL server, ама такова нещо не срещнах.
Отг: къде го чете пък това?
MSSQL7 Book online --> ako na towa mu wikate nenadejdna literatura ... ok ;)
Kolkoto za sywmestimostta: Nameri statijata i ja procheti tam si pishe. 12/12/99 e razlichno ot 12/12/99 12:56:87.77 nali ? obache ednoto se sydyrja w drugoto ( i ste se sydyrja kakwato i da e realizacijata, moje da se promeni samo convert func. ). Prosto, logichno i prowereno ( ne samo ot mene :)
Kolkoto za sywmestimostta: Nameri statijata i ja procheti tam si pishe. 12/12/99 e razlichno ot 12/12/99 12:56:87.77 nali ? obache ednoto se sydyrja w drugoto ( i ste se sydyrja kakwato i da e realizacijata, moje da se promeni samo convert func. ). Prosto, logichno i prowereno ( ne samo ot mene :)
добре.
и какъв точно like ще приложиш (без convert) ако в един момент SQL Server-a реши да имплицитно да конвертира датата не до формат "mm/dd/yyyy hh:mm:ss" (какъвто между другото, е сегашният default), а например до "hh:mm:ss mm/dd/yyyy"? къде точно ще отиде твоя like? на луната за печурки... така че, добре, там си го чел, обаче сигурно е имало и някаква забележка за такова използване - освен ако са решили, че тоя проблем е очевиден. още повече, че тва решение е МНОООГО бавно - не ползва индекс (на 2000 е възможно да се сложи такъв индекс, но не ти го препоръчвам), смята ВСИЧКИ дати, въобще... а иначе, books online са си много хубаво организирани, аз също ги ползвам за "първа инстанция" ;)
Отг: добре.
Irazil sym se netochno. Sorry. Imah wpredwid che Convert moje da se promeni - towa e prosto element ot ezika, dokato idejata zalojena w LIKE srawnenito ste si ostane.
"mm/dd/yyyy hh:mm:ss" i "hh:mm:ss mm/dd/yyyy" sydyrjat "mm/dd/yy" nali ? Wij ako imash lokalen format na datata -- imash problem, no ne za towa stawa duma sega, nali? ( A i dori towa lesno se zaobikalja. )
Zabelejka w documentacijata ima razbira se ( ne sym obyrnal wnimanie no sym siguren ), ako iskash da srawnish 2 DATETIME -- izpolzwaj "=". Wyprosyt e che ti ne iskash da srawnish 2te dati, a prosto tyrsish sywpadenie na dd/mm/yyyy, nali?
BTW: Estestweno drugoto reshenie na problema e DATEDIFF, no chestno kazano ne sym go polzwal t.k LIKE si e cool.
"mm/dd/yyyy hh:mm:ss" i "hh:mm:ss mm/dd/yyyy" sydyrjat "mm/dd/yy" nali ? Wij ako imash lokalen format na datata -- imash problem, no ne za towa stawa duma sega, nali? ( A i dori towa lesno se zaobikalja. )
Zabelejka w documentacijata ima razbira se ( ne sym obyrnal wnimanie no sym siguren ), ako iskash da srawnish 2 DATETIME -- izpolzwaj "=". Wyprosyt e che ti ne iskash da srawnish 2te dati, a prosto tyrsish sywpadenie na dd/mm/yyyy, nali?
BTW: Estestweno drugoto reshenie na problema e DATEDIFF, no chestno kazano ne sym go polzwal t.k LIKE si e cool.
добре де! :)
напиши ми like-маска, която работи и при двата формата - "mm/dd/yyyy hh:mm:ss" и "hh:mm:ss dd/mm/yyyy". по еднакъв начин, без предварително да знаеш кой се използва. забележи, че реда на месеца и деня в двете не е един и същ. дори само за тези два формата става проблем сравнението чрез like. плюс това, наистина е бая по-бавно, вместо да сравняваш с DateTime, щото like няма как да използва прост индекс. а DateTime получаваш, като convert-неш varchar от типа на "06/17/1999", примерно. това решение ще ходи по евентуалния индекс. нейсе де. все пак, ако опреш до дати, препоръчвам ти поне да пробваш тоя метод ;).