2008-09-17 28 views
0

Wenn ich über einen Parameter Daten an eine gespeicherte Prozedur übergebe, bin ich ein wenig verwirrt darüber, welches Format für die Daten verwendet werden soll. Meine ursprüngliche VBA-Syntax verwendet, um das Objekt ADO-Verbindung die gespeicherte Prozedur auszuführen:Gespeicherte Prozeduren mit Datumsparametern ausführen: Command Object vs. Connection-Objekt

Set SentDetailRS = Me.ADOConnectionToIntegrity.Execute("dbo.s_SelectAggregatedSentDetailList '" & fCSQLDate(EffectiveDate) & "'", , adCmdText) 

Dies funktioniert gut für mich mit dem Datum Syntax yyyy-mm-dd aber wenn ein anderer Benutzer führt den Code sie den Fehler empfangen: 13 ‚Type Mismatch‘.

Nach einigem Experimentieren fand ich, dass das Liefern des Datums im Format diesen Fehler für den Benutzer behebt, aber jetzt gibt mir der Fehler!

Die Ausführung der gespeicherten Prozedur mit einem Befehlsobjekt mit Parametern funktioniert unabhängig vom Format des Datums (ich nehme an, ADO kümmert sich um die Formatierung hinter den Kulissen). Ich dachte, dass die Verwendung des Formats yyyy-mm-dd universell mit SQL Server funktionieren würde?

Ich bin auch ratlos, warum dieses Problem benutzerspezifisch zu sein scheint? Ich habe festgestellt, dass meine Standardsprache auf SQL Server "Englisch" ist, während die Standardsprache des anderen Benutzers "Britisches Englisch" ist. Könnte das das Problem verursachen?

Ich benutze ADO 2.8 mit Access 2003 und SQL Server 2000, SQL Server Login ist über Windows integrierte Sicherheit.

Antwort

1

Seien Sie vorsichtig und glauben Sie nicht, dass ADO sich um das Problem kümmert. Das universelle SQL-Datumsformat ist 'JJJJMMTT', während sowohl SQL als auch ACCESS von den regionalen Einstellungen der Maschine in der Art und Weise beeinflusst werden, wie sie Datumsangaben anzeigen und sie in Zeichenfolgen konvertieren.

Sie, dass die Datumstrenn nicht vergessen ist # in Access, während es in SQL

Mein bester Rat systematisch wird es sein, Ihre Access # MM-DD-YYYY # (oder ähnlich) in konvertieren 'ist YYYYMMDD' bevor Sie die Anweisung an Ihren Server senden. Sie könnten eine kleine Funktion bauen wie:

Public function SQLdateFormat(x_date) as string 

SQLDateFormat = _ 
    trim(str(datePart("yyyy",x_date))) & _ 
    right(str(datePart("m",date)),2) & _ 
    right(str(datePart("d",date)),2) 

    ''be carefull, you might get something like '2008 9 3' 
SQLDateFormat = replace(functionSQLDateFormat," ","0") 
    '' you will have the expected '20080903' 

End function 

Wenn Sie nicht programmatisch Sie Ihre INSERT/UPDATE Zeichenfolge bauen, bevor sie an den Server gesendet werden, werde ich dann Sie beraten die regionalen Einstellungen aller Maschinen an die wenden regionale Einstellungen der Maschine, die SQL hostet. Möglicherweise müssen Sie auch überprüfen, ob ein bestimmtes Datumsformat auf Ihrem SQL-Server vorhanden ist (ich bin mir nicht sicher). Persönlich löste ich diese Art von Lokalisierungsproblemen (es kommt auch vor, wenn Koma als Dezimaltrennzeichen in Französisch verwendet wird) oder SQL - spezifische Zeichenprobleme (wenn Anführungszeichen oder doppelte Anführungszeichen in einer Zeichenfolge sind) durch Zurückziehen der SQL - Anweisungen vor dem Senden an die Server.

0

Ich würde vermuten, dass fCSQLDate-Funktion ist kulturspezifisch - d. H. Es wird das Datum basierend auf den Gebietsschemaeinstellungen des Benutzers analysieren. Deshalb sehen Sie das Problem.

Wie auch immer, die Verwendung von Abfragen mit verketteten Strings ist immer eine schlechte Idee (Injektionsangriffe). Sie sind besser dran, wenn Sie Parameter verwenden.

0

Access verwendet # als Datumsfeldbegrenzer. Das Format sollte # mm/dd/yyyy # sein, wahrscheinlich funktioniert auch # mm-dd-yyyy #.

0

Sorry, ich kenne mysql nicht, aber mit oracle würde ich immer explizit das Format angeben, in dem ich das Format erwartet habe, zB: 'DD-MM-YYYY', um (regionale) Datumsformatprobleme zu vermeiden

0

Warum verwenden sie das Format nicht

dd mmm yyyy 

es gibt nur einen Weg, es interpretiert werden kann.

0

Sie können die Funktion Date() verwenden, um basierend auf den Datums- und Uhrzeiteinstellungen des Systems ein universelles Datum zurückzugeben. Die Regionseinstellungen auf dem Computer bestimmen, wie er auf dem Client formatiert wurde. Wenn Sie das Feld strictle als DateTime-Feld belassen, können die Einstellungen in cleint region das Datum formatieren.

In den Server gehen, sollte die Funktion Date() auch funktionieren (Rückgabe eines universellen Datumswerts).

Verwenden Sie außerdem ein Befehlsobjekt und Parameter in Ihrer Abfrage, wenn Sie sie übergeben, um SQL Injection-Angriffe auf Zeichenfolgenfelder zu vermeiden.

Verwandte Themen