Black Friday = Pricewatch Bekijk onze selectie van de beste Black Friday-deals en voorkom een miskoop.
Toon posts:

[SQL 2005] SP werkt niet, datetime format

Pagina: 1
Acties:

Verwijderd

Topicstarter
Hallo,

ik heb een probleem. We zijn overgegaan van SQL 2000 naar SQL 2005.

Alle Stored Procedures ( SP ) werken behalve 1.

code:
1
2
3
4
5
6
7
8
9
10
11
12
USE [WebSyncSource]
GO

DECLARE @return_value int

EXEC    @return_value = [dbo].[Sync_Objects_FillTmp]
        @SyncPartial = 1,
        @SyncDate = N'06/11/2008'

SELECT  'Return Value' = @return_value

GO


Deze geeft als output:
Msg 8114, Level 16, State 5, Procedure Sync_Suppliers_FillTmp, Line 0
Error converting data type varchar to datetime.

(1 row(s) affected)


Deze SP gebruik ik ook voor andere tabellen en hier werkt hij wel in.

Deze tabellen zijn hetzelfde en @SyncDate kijkt in beide SP's naar dezelfde kolom.

In beide tabbellen staat ook de waarde "NULL", hier kan het dus ook niet aan liggen.

Vul ik in de query hard een datum is '29/10/2008', dan geeft hij onderstaande foutmelding

Msg 242, Level 16, State 3, Procedure Sync_Suppliers_FillTmp, Line 31
The conversion of a char data type to a datetime data type resulted in an out-of-range datetime value.
The statement has been terminated.

(1 row(s) affected)

[ Voor 24% gewijzigd door Verwijderd op 06-11-2008 19:27 ]


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Ik vermoed dat je locale instellingen veranderd zijn (bijv. en-us mm/dd/yyyy naar nl-nl dd-mm-yyyy, gezien je tweede foutmelding) of ergens (maar dat blijkt duidelijk uit de eerste foutmelding) wordt een datum geïnterpreteerd als string (varchar). Controleer dus even alle plekken waar datums gebruikt worden. Overigens kun je daarom beter de ISO8601 notatie (yyyymmdd) gebruiken; dat gaat altijd goed ;)

[ Voor 33% gewijzigd door RobIII op 06-11-2008 19:42 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Verwijderd

Topicstarter
HIj gaat nu wel verder als ik 2008/10/29 gebruik.

Ik ga het nu testen.

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Verwijderd schreef op donderdag 06 november 2008 @ 19:34:
HIj gaat nu wel verder als ik 2008/10/29 gebruik.

Ik ga het nu testen.
Vermoedelijk zijn je landinstellingen dus gewijzigd. Is SQL2K5 op de oude server geïnstalleerd of op een nieuwe? In het laatste geval (en eigenlijk ook in het eerste) dus even in je configuratiescherm je landinstellingen controleren.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Verwijderd

Topicstarter
Msg 241, Level 16, State 1, Procedure Sync_Suppliers_FillTmp, Line 28
Conversion failed when converting datetime from character string.



Er moet dus iets in dat veld staan wat geen datum is.

Land instellingen lijken mij niet, omdat het voor de andere tabellen (9 in totaal) wel goed gaat.

In de WHERE staat:

code:
1
Suppliers.Last_Updator_Date_Time >= @SyncDate

SyncDate is nu 2008/10/29

Als ik alles weer automatisch laar verlopen en ik zet de tijd op 06/11/2008 (auto) Dan gaat alles wel goed.

Als ik hem een paar dagen terug zet, dan werkt het niet meer.

[ Voor 32% gewijzigd door Verwijderd op 06-11-2008 20:03 ]


  • CMG
  • Registratie: Februari 2002
  • Laatst online: 10-12-2024

CMG

RobIII schreef op donderdag 06 november 2008 @ 19:31:
Ik vermoed dat je locale instellingen veranderd zijn (bijv. en-us mm/dd/yyyy naar nl-nl dd-mm-yyyy, gezien je tweede foutmelding) of ergens (maar dat blijkt duidelijk uit de eerste foutmelding) wordt een datum geïnterpreteerd als string (varchar). Controleer dus even alle plekken waar datums gebruikt worden. Overigens kun je daarom beter de ISO8601 notatie (yyyymmdd) gebruiken; dat gaat altijd goed ;)
Je mag er ook streepjes (dashes) tussen zetten, 2008-11-06 22:40:03.284 is ook altijd parseable bijv.
Wat ook mag:
2008-11-06
2008-11-06 22:40
2008-11-06 22:40:03

NKCSS - Projects - YouTube


  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
CMG schreef op donderdag 06 november 2008 @ 20:41:
[...]

Je mag er ook streepjes (dashes) tussen zetten, 2008-11-06 22:40:03.284 is ook altijd parseable bijv.
Wat ook mag:
2008-11-06
2008-11-06 22:40
2008-11-06 22:40:03
Er mag nog wel meer, maar dat is een kwestie van even de link (en dan weer de ISO link) volgen ;)

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


  • Sikkek
  • Registratie: Maart 2004
  • Laatst online: 18:09
Verwijderd schreef op donderdag 06 november 2008 @ 19:47:
In de WHERE staat:
code:
1
Suppliers.Last_Updator_Date_Time >= @SyncDate
Wat voor veldtype is Suppliers.Last_Updator_Date_Time? Is dat wel een datetime veld?

Verwijderd

Topicstarter
Handmatig kopieren werkte wel, dit voor 10635 record gedaan :'(

De automatische job werkt nu weer. Waanerschijnlijk zal er toch 1 tussen 10635 record fout zijn gegaan.

Nu werkt het wel.

Probeer nu de DTS (of SSIS) job werkend te krijgen. Hier open ik wel een nieuw topic voor

  • _js_
  • Registratie: Oktober 2002
  • Laatst online: 25-10 14:28
Verwijderd schreef op donderdag 06 november 2008 @ 19:47:
Msg 241, Level 16, State 1, Procedure Sync_Suppliers_FillTmp, Line 28
Conversion failed when converting datetime from character string.



Er moet dus iets in dat veld staan wat geen datum is.

Land instellingen lijken mij niet, omdat het voor de andere tabellen (9 in totaal) wel goed gaat.

In de WHERE staat:

code:
1
Suppliers.Last_Updator_Date_Time >= @SyncDate

SyncDate is nu 2008/10/29

Als ik alles weer automatisch laar verlopen en ik zet de tijd op 06/11/2008 (auto) Dan gaat alles wel goed.

Als ik hem een paar dagen terug zet, dan werkt het niet meer.
Dit geeft weer aan dat er iets mis is met de land- / taalinstellingen.
De datum zal worden gelezen als 11 juni ipv 6 november, wat weer leidt tot foute resultaten in je database.
Pagina: 1