A little help ...

24 отговора 394 прегледа
#1

A little help ...

Здравейте! Ще ми се пак да попитам за нещичко, което е следното:
значи имам си една прекрасна базичка на SQL-а. Правя си едно куири от типа
select вземи_всичко
from там_и_там
where така_и_така
където условието ми е datastart = 'датата',
и сервера пищи : не може така два разлини типа данни - datetime i varchar. Ок от моя страна и му праскам едно Convert(datatype(lenght), expression, format). Аз лично ползвам формат 111. Хареса му. Обаче нищо не ми връща, т.е връща ми 0 rows. А би трябвало да ми върне повече от 2 rows. Някаква идея. Явно че converta нещо го бъркам.
Мерси предварително...

Отговор
в отговор на Веселина #2

Отг: 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)

Отговор
в отговор на Веселина #3

Следната заявка

SELECT * FROM MYTABLE WHERE MYDATE = '8/28/00'
При мен си върви.
Да не би настройката на някой от дриверите да не е добра и драйвера да конвертира датата до нещо друго?
С ODBC ли си? Нали си на MSSQL - опитай в Enterprise manager.
Последната идея - пусни trace на SQL сървера и виж каква точно заявка пращаш.

Отговор
в отговор на Жоро #4

Отг: Следната заявка

Да с ODBC съм. Пуснах го сто пъти на Query Analyzer и пак не ми връща резултат. Хм, трябваше да спомена че Mydata е от типа datatime datatype. Базата ми е на SQL сервера. Пусках го и така както е предложението, но упорито ми връща резултат 0 rows, което не е вярно.

Отговор
в отговор на Мечо Пух #5

Хм,

Идея първа: опитай следния формат '1/24/00', после '24/1/00'. разбира се вкарай валидни записи.
Втора: - какво ти дава SQL trace?
И моята дата беше datetime type

Отговор
в отговор на Жоро #6

Отг: Хм,

разбира се че го пускам с валидни данни. И така и онака и все ми връща 0 реда. Второ ако му задам
mydata = '../../..' типраска грешка, от типа "ало къде така два различни типа данни", за това използвам convert.

Отговор
в отговор на Веселина #7

ако някой се интересува...

проблема е в не съвсем точно използване на convert-функцията. в общи линии, 111 се използва, ако format-a е yyyy/mm/dd, а 11 - ако format-а е yy/mm/dd. усещате ли разликата? ми да, сигурно няма записи от 0099 година :).
четете бе хора - то си го пише в books online (е и аз не се усетих веднага ;), признавам си)

Отговор
в отговор на Кромид #8

Веселина,

Това ли беше проблема? :-)
Затова ти казах пусни trace-to :-).
Надявам се да нямаш проблем вече :-)


Отговор
в отговор на Жоро #9

Отг: Веселина,

Жоро не съвсем, не това баш проблема. Защото ис формат 11 демек гг/мм/дд, пак връща 0 ред, демек пак нчма данни. Та целия номер е в това че трябва да му дам и часа и минутите. Т.е в базата даните в datetime са ми записани барабар с часа (то това ми требе де) и когато му задам условието върни ми всичко за дадената дата (без часа) ми връща 0 реда, когато му задам датата + часа си заспива идеално. Та според мен те това ми беше "спъни камука".
мерси на всички ... (и май до скоро, хихи)..

Отговор
в отговор на Веселина #10

да,

обаче и да беше се сетила за часовете в датата, със 111 нямаше да тръгне ;)

и, Жоро, съмнявам се, че trace щеше да помогне - специално за случая. абе въобще, вършел ли ти е работа за нещо друго, освен за статистика(брой повиквания, скорост, натоварвания, колко пъти прави еди-кво си)?

Отговор
в отговор на Кромид #11

Отг: да,

Да бе, така е. Имам в предвид за 11 и 111. Съгласна съм, че ми помогна. И много, много мерси .И даже и черпня ще има, както се разбрахме.

Отговор
в отговор на Веселина #12

Отг: да,

и пържени картофи! иначе ник'ва помощ повече! и крем карамел! и шкембе чорба. нещо тарифа за услуги да съм окачил някъде? ясен ми е(горе-долу) тоя сървър, обаждам се... човек да не те бъзикне на професионална тема... тва, младото поколение, сте много докачливи бе ;) айде, че ме юркат...



Отговор
в отговор на Кромид #13

Отг: да,

Бре а наливната бира къде я забрави? Че тя е основен елемент в черпнята, primary key така да се каже.

Отговор
в отговор на Веселина #14

Отг: 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..."



Отговор
в отговор на jaw #15

къде го чете пък това?

щото на някакво научно-популярно четиво ми прилича ;). без да се обиждаш, май не си подбрал точния цитат, или поне не целия - в какъв вид е датата, като се превърне до varchar? и ако пишеш нещо, дето се очаква да надживее текущата версия на SQL Server-a, не би ли сложил все пак един convert, ей така, за всеки случай, да не би M$ да реши в някоя следваща версия да смени вида на датата, имплицитно конвертирана до varchar?

Отговор
в отговор на Кромид #16

Отг: къде го чете пък това?

да бе кажи къде го чете, щото сума ти хелпове изчетох, барабар с една тухла 1200 стр. SQL server, ама такова нещо не срещнах.

Отговор
в отговор на Веселина #17

Отг: къде го чете пък това?

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 :)

Отговор
в отговор на jaw #18

добре.

и какъв точно like ще приложиш (без convert) ако в един момент SQL Server-a реши да имплицитно да конвертира датата не до формат "mm/dd/yyyy hh:mm:ss" (какъвто между другото, е сегашният default), а например до "hh:mm:ss mm/dd/yyyy"? къде точно ще отиде твоя like? на луната за печурки... така че, добре, там си го чел, обаче сигурно е имало и някаква забележка за такова използване - освен ако са решили, че тоя проблем е очевиден. още повече, че тва решение е МНОООГО бавно - не ползва индекс (на 2000 е възможно да се сложи такъв индекс, но не ти го препоръчвам), смята ВСИЧКИ дати, въобще... а иначе, books online са си много хубаво организирани, аз също ги ползвам за "първа инстанция" ;)

Отговор
в отговор на Кромид #19

Отг: добре.

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.

Отговор
в отговор на jaw #20

добре де! :)

напиши ми like-маска, която работи и при двата формата - "mm/dd/yyyy hh:mm:ss" и "hh:mm:ss dd/mm/yyyy". по еднакъв начин, без предварително да знаеш кой се използва. забележи, че реда на месеца и деня в двете не е един и същ. дори само за тези два формата става проблем сравнението чрез like. плюс това, наистина е бая по-бавно, вместо да сравняваш с DateTime, щото like няма как да използва прост индекс. а DateTime получаваш, като convert-неш varchar от типа на "06/17/1999", примерно. това решение ще ходи по евентуалния индекс. нейсе де. все пак, ако опреш до дати, препоръчвам ти поне да пробваш тоя метод ;).

Отговор