[SQL] Query via ODBC met time field geeft fout

[eatualive]

Beste Mensen,

Ik ben bezig scripts te schrijven voor een nieuw systeem voor ons die communiceerd met een SQL database versie 2012 64bit. Ik communiceer d.m.v. een file dsn(ODBC) met de database.

Ik wil een eenvoudige selectie op een tabel uitvoeren en de waardes op het scherm weergeven.
Nu loop ik telkens tegen dezelfde fout. Bij het uitvoeren van het SQL script krijg ik telkens de melding:

[Microsoft][SQL Server Native Client 11.0] Numeric value out of range

Na heel veel testen lijkt het erop dat dit komt door de time fields die ik in mijn tabel heb staan.
Als ik een selectie maak van een kolom zonder time dan werkt mijn script naar behoren.
Maar zodra ik specifiek de time kolom selecteer krijg ik deze error. Ik krijg ook een error als ik alle kolommen selecteer. Alle time fields zijn van het format Time(0).

[script]

strSQL = "SELECT * FROM dbo.t_Line"
Set rst = conn.Execute(strSQL)

[/script]

Ik zie totaal geen rede waarom dit het geval moet zijn aangezien het alleen een selectie is waarna ik de gegevens gewoon op het scherm print. Weet iemand waardoor dit kan komen? Op internet heb ik dingen gelezen gerelateerd naar het date/time format maar ik heb alleen time.

Het script geeft geen fouten als ik het volgende doe:
[script]

strSQL = "SELECT LineName FROM dbo.t_Line"
Set rst = conn.Execute(strSQL)

[/script]

Mijn LineName is een string. Voor alle duidelijkheid ik doe op dit moment nog niks met de times die in mijn recordset komen. Dus de melding komt niet door andere code. Het gaat echt fout op de selectie statement.

[joppybt]

Kun je in plaats van met ODBC eens met een andere tool/driver kijken wat er daadwerkelijk in de database staat bij die velden?
Iets soortgelijks heb ik wel eens meegemaakt met Oracle datum die in de database op 31-12-0012 stonden in de database. Sommige drivers bleken geen datums 2000 jaar geleden te ondersteunen en gaven ook heel onduidelijke foutmeldingen.
Misschien dat er dus niet-geldige tijdstippen in je database staan zoals 26h13m00s o.i.d. en dat de driver dat niet leuk vind?

[eatualive]

Ik begrijp wat je bedoeld maar ik weet zo niet hoe ik dat zou moeten doen. Ik kan natuurlijk wel inloggen op mijn database met de sql management studio. In de database staan maar 2 tijden:

18:00:00 en 10:00:00 en deze heb ik handmatig erin gezet om te testen. Het lijkt dat het goed gekeurd word aangezien ik 10:00 invoer en dan maakt hij er 10:00:00 van. Zo gauw ik iets boven de 24 uur invul dan krijg ik de melding overflow. Dus de database controleerd dit automatisch.

Edit: Ik heb even alle tijd waardes de waarde NULL gegeven. Nu kan ik wel met een SELECT * alles selecteren zonder fout. Kortom de fout zit in de tijd notatie/format??

Maar dan nog snap ik het niet. Wat kan er fout gaan aan tijd tenzij het een bug in de driver betreft.
Dan zou ik het met een andere driver moeten testen. Maar zou niet weten of er een 3rd party driver is om te communiceren met de SQL database.

[ Voor 30% gewijzigd door eatualive op 17-09-2013 09:06 ]

[eatualive]

Ok na veel vechten en testen blijkt de fout in de precisie te zitten van het time format.
Time(0), Time(1), Time(2), Time(3) geven deze error.

Als ik mijn veld op Time(4), Time(5), Time(6), Time(7) zet werkt het zonder problemen.Het is geen heel groot probleem om het zo op te lossen maar ik probeer mijn data zo klein mogelijk te houden. De tijd die ik straks ga opslaan heeft een maximale precisie van 1 minuut dus waarom het veld zo precies maken.

Als iemand een goede beredenering heeft hoor ik dat graag want daar ben ik wel benieuwd na.
Maar het probleem is in iedergeval opgelost.

[TallManNL]

Als je echt je data zo kort mogelijk wil opslaan kun je natuurlijk in je select je Time(0) naar een Time(4) of hoger casten. Dat is wel minder ideaal kwa performance maar je bespaart jezelf toch wel 1 a 2 bytes per time veld. Andere optie is je minuten waar je op gaat opslaan opslaan als een smallint, bespaar je nog een byte t.o.v. time(0) en omrekenen naar de daadwerkelijke tijd is natuurlijk heel simpel.

Ik zou gewoon de langere opslag kiezen, ook al heb je per record 10 time velden en 1 miljoen records, dan heb je het in totaal over 30MB meer data (smallint naar time(7)). Daarop zou ik niet gaan zitten optimaliseren, casten of rekenen.

Is er een bepaalde reden dat je ODBC gebruikt voor je connectie? Mogelijk dat je met andere methoden deze problemen helemaal niet hebt.

[eatualive]

Het is niet zo dat ik veel records zal krijgen in deze situatie maar toch, ik probeer overal een logica door te voeren. Al kan ik nu leven met deze oplossing. Ik gebruik file DSN omdat het makkelijk is dat ik een bestandje heb met daarin de alle gegevens.
Nu ga ik ervan uit dat file dsn via odbc loopt aangezien ik het bestandje aanmaak in windows onder ODBC in het configuratie scherm...

Deze kan ik dan eenvoudig aanroepen in mijn SCADA applicatie. Als ik de applicatie vervoglens ga draaien op een andere PC (Client) maar de database staat op de server dan moet ik hooguit de file DSN aanpassen en dan kan alles door blijven draaien. Ik wil namelijk geen aanpassingen in mijn applicatie gaan voeren als ik iets verhuis.

Misschien zijn er meer mogelijkheden waardoor dit ook eenvoudig kan maar daar heb ik geen kennis van.
Nieuwe mogelijkheden zijn altijd welkom, maar anders blijf ik bij oud en vertrouwd.

[ Voor 34% gewijzigd door eatualive op 18-09-2013 10:16 ]