[SQL2000/2005] vreemd probleem

[davhor]

Ik ben overgestapt van SQL2000 server naar een 2005. Nu werkt alleen een belangrijke query niet meer. Het is echter een vreemd probleem. Weet iemand waar het aan kan liggen. Heb Google afgezocht en daar kwamen ze eerst op problemen met de datumweergave, maar na lang prutsen kwam ik daar niet tot een oplossing. Haal ik de datumvergelijking in het WHERE gedeelte weg, dan doet de query het. Dit zelfde geldt als ik de datum daar laat staan, maar als ik de bedrijfsvergelijking in het WHERE gedeelte weghaal, dan doet hij het ook. Maar als ze er allebei staan, werkt de query niet meer en krijg ik de volgende melding:

Conversion failed when converting the varchar value 'J' to data type int.

Hieronder de SQL:

code:

SELECT TOP (100) PERCENT CONVERT(DateTime, CONVERT(Int, Datum.sData) - 2) AS
Datum, Bedrijf.sShowData AS Bedrijf
FROM dbo.tProjectKenmerk1 LEFT OUTER JOIN dbo.tProjectKenmerk1FF AS Bedrijf ON
dbo.tProjectKenmerk1.lCounter = Bedrijf.lKey RIGHT OUTER JOIN dbo.tProjectKenmerk1FF AS
Datum ON dbo.tProjectKenmerk1.lCounter = Datum.lKey
WHERE (Datum.lFieldID = 63) AND (Bedrijf.lFieldID = 70) AND (CONVERT(DateTime,
CONVERT(Int, Datum.sData) - 2) > CONVERT(DATETIME, 3 - 6 - 2008, 102)) AND
(Bedrijf.sShowData = 'Bedrijfsnaam')

[whoami]

Mag ik eerst eens vragen welk datatype je gebruikt voor het opslaan van die datum ?
Waarom doe je CONVERT(DATETIME, 3-6-2008) ? (Waarom zet je daar geen quotes) ? Waarom maak je geen gebruik van de 'getdate()' functie om de huidige datum te bekomen ?
Waarom maak je geen gebruik van datediff om die records te bekomen die meer dan 2 dagen in de toekomst liggen (want ik vermoed dat het dit is wat je wil doen ? )

[sig69]

Ik vermoed dat je datums als varchar opslaat?

Haal ik de datumvergelijking in het WHERE gedeelte weg, dan doet de query het.

Conversion failed when converting the varchar value 'J' to data type int.

Staat er niet ergens "Jan xxxxxx" in de database?

maar als ik de bedrijfsvergelijking in het WHERE gedeelte weghaal, dan doet hij het ook.

Waarschijnlijk maakt het foutieve record nu geen onderdeel meer uit van de resultset?

Maw:
• Kijk in de datase wat er nu eigenlijk exact staat.
• Post je database structuur / datatypen even.

[ Voor 10% gewijzigd door sig69 op 03-06-2008 11:54 ]

[RobIII]

Een datum in een query mag je noteren als (bijv) 'yyyymmdd' (dus '20080502') of 'yyyymmdd hh:nn:ss' ofzo. Verder: zie whoami.

[davhor]

whoami schreef op dinsdag 03 juni 2008 @ 11:48:
Mag ik eerst eens vragen welk datatype je gebruikt voor het opslaan van die datum ?
Waarom doe je CONVERT(DATETIME, 3-6-2008) ? (Waarom zet je daar geen quotes) ? Waarom maak je geen gebruik van de 'getdate()' functie om de huidige datum te bekomen ?
Waarom maak je geen gebruik van datediff om die records te bekomen die meer dan 2 dagen in de toekomst liggen (want ik vermoed dat het dit is wat je wil doen ? )

Bij het orgineel heb ik wel quotes, maar blijkbaar met het kopiëren van de vereenvoudige versie zijn deze vervallen. Ze staan er dus wel.

Het is niet de bedoeling dat ik de huidige datum krijg, maar een ingevoerde via listbox en dan als een parameter in de SQL (maar omdat de query in de programmeercode niet werkt, ben ik gaan debuggen in SQL Server en heb ik een vaste datum gekozen, waarbij ik ook nog passende records heb).

Aangezien er een weergave moet komen van 2 dagen voor de geselecteerde datum heb ik die -2 in de code toegepast. Haal ik die hele - 2 functionaliteit uit de query, blijft hij fout gaan.

Het datumveld in de database is in werkelijkheid een nummer in een tekstveld 38867, daarom gebruik ik de convertfunctie om geen appels met peren te vergelijken. Ik kan dat veld ook niet aanpassen in de database, aangezien het een bestaande database van ons CRM-pakket is.

[davhor]

sig69 schreef op dinsdag 03 juni 2008 @ 11:54:
Ik vermoed dat je datums als varchar opslaat?

[...]


[...]

Staat er niet ergens "Jan xxxxxx" in de database?

[...]

Waarschijnlijk maakt het foutieve record nu geen onderdeel meer uit van de resultset?

Maw:
• Kijk in de datase wat er nu eigenlijk exact staat.
• Post je database structuur / datatypen even.

Ik ga eens records bestuderen (zijn er maar 7000), maar als het het probleem oplost!! Ik kom erop terug.

[sig69]

Maniac schreef op dinsdag 03 juni 2008 @ 11:58:
[...]


Ik ga eens records bestuderen (zijn er maar 7000), maar als het het probleem oplost!! Ik kom erop terug.

Je kan er ook gewoon even een query tegenaan gooien natuurlijk...

[davhor]

sig69 schreef op dinsdag 03 juni 2008 @ 12:05:
[...]

Je kan er ook gewoon even een query tegenaan gooien natuurlijk...

Wellicht een goed idee! Ga ik doen.

[Robtimus]

Omdat de foutmelding het over een int heeft en het probleem weg is als de WHERE verdwijnt, zegt iets zegt me dat het in Datum.sData zit. Voer even de volgende query uit:

SQL:

SELECT sData FROM Datum WHERE sData LIKE '%J%'

Wellicht dat SQL 2000 wat soepeler omgaat met foutieve waarden, wellicht dat deze nieuwe waarde na de migratie in de database is gekomen.

[davhor]

Ben nog steeds bezig met debuggen. Bovenstaande acties uitgevoerd, maar nog niks kunnen vinden. Denk dat het een gebrek is in de database (en de onderlinge relaties daarin). Ik ga verder met debuggen en als ik iets leuks vind laat ik het jullie weten.

[Meekoh]

Heb je misschien een voorbeeldje van wat er in sData staat?
Heb je trouwens zelf al gekeken naar wat dit je oplevert?

SQL:

SELECT CONVERT(DATETIME, 3 - 6 - 2008, 102)

Is het je bedoeling dat dit er komt te staan? "1894-06-30 00:00:00.000"

[LuCarD]

Moshe85 schreef op woensdag 04 juni 2008 @ 09:58:
Heb je misschien een voorbeeldje van wat er in sData staat?
Heb je trouwens zelf al gekeken naar wat dit je oplevert?

SQL:

SELECT CONVERT(DATETIME, 3 - 6 - 2008, 102)

Is het je bedoeling dat dit er komt te staan? "1894-06-30 00:00:00.000"

Zoals hij al had gezegt, de quotes om de datum heen zijn weggevallen. Met quotes werkt het namelijk wel.

[Meekoh]

LuCarD schreef op woensdag 04 juni 2008 @ 10:14:
[...]


Zoals hij al had gezegt, de quotes om de datum heen zijn weggevallen. Met quotes werkt het namelijk wel.

Aah ok, maar dan nog wat voor data moeten we verwachten in sData?
Staat die SQL 2005 instance ook op een andere server? Zoja check de cultural settings

[ Voor 13% gewijzigd door Meekoh op 04-06-2008 10:58 ]

[LuCarD]

Misschien ligt het aan mij, maar klopt je datamodel wel? Zodra ik namelijk tabelnamen zie met nummers dan gaat er bij mij altijd een alarmbel rinkelen.

Maar goed, het werkte altijd dus waarom nu niet meer...

Kan het zijn dat in SQL2000 de waardes die niet konden worden geconverteerd naar int er al waren uitgefilterd door andere condities van de where clause. Bij voorbeeld die Datum.lFieldID = 63 of zo? Het kan namelijk heel goed dat SQL2005 een andere query path gebruikt.

[davhor]

Ik heb het idee dat het query-pad inderdaad anders is in 2005 dan in 2000. Het lijkt erop dat hij eerst de datum filter probeert te doen, waarbij ik het veld naar een integer verander. Er staan echter nog meer velden in deze tabel welke niet naar een integer zijn te converten. In 2000 filterde hij deze velden er eerst uit door Datum.lFieldID = 63. Het lijkt erop dat hij deze nu achteraf pas uitvoert en eerst de convert datum naar integer.

Ik heb de query nu wel draaiend en ben daar erg blij mee! Heb het volgende gedaan:

code:

SELECT TOP (100) PERCENT CONVERT(DateTime, CONVERT(Int, Datum.sData) - 2) AS
Datum, Bedrijf.sShowData AS Bedrijf
FROM dbo.tProjectKenmerk1 LEFT OUTER JOIN dbo.tProjectKenmerk1FF AS Bedrijf ON
dbo.tProjectKenmerk1.lCounter = Bedrijf.lKey RIGHT OUTER JOIN dbo.tProjectKenmerk1FF AS
Datum ON dbo.tProjectKenmerk1.lCounter = Datum.lKey
WHERE (Datum.lFieldID = 63) AND (Bedrijf.lFieldID = 70) AND Datum.sData > ? AND
(Bedrijf.sShowData = 'Bedrijfsnaam')

De vraagteken vul ik nu vanuit de programmeercode met het getal welke voor de datum staat. Nu vergelijk ik gewoon twee tekstvelden en heb ik geen probleem. De bovenste convert staat er nog steeds in en wordt wel goed uitgevoerd.

Dank voor alle hulp!