Umstellung von Oracle zu MSSQL Problem bei ein paar ODBC abfragen

[t-sql]

Läuft die Abfrage wenn Du die beiden Daten direkt in deiner Abfrage anstelle der ? einträgst?

 

[Voosjey]

wenn ich das Datum per Hand eintrage dann funktioniert es. Also wenn ich '2024-08-28' und '2024-10-06' eintrage, läuft es ohne Probleme

 

[t-sql]

wenn ich das Datum per Hand eintrage dann funktioniert es. Also wenn ich '2024-08-28' und '2024-10-06' eintrage, läuft es ohne Probleme

Gut, also ist es kein Problem der Abfrage sondern wie die Daten von Excel dorthin übertragen werden. Kannst Du Dir im Excel die Abfrage anzeigen lassen?

 

[dabadepdu]

Excel kennt keine Typen, nur Formatierung. Das was du als "Datum" einträgst, von Hand, ist ein String, der ein Datum enthält, das je nach Nation / Muttersprache auch von einem Menschen nicht zwangsläufig richtig interpretiert würde.

Unter Oracle ist es so, dass ein Default Datums Format angeben wird, das bei der Interpretation von Strings, die mit einem Datumstyp verglichen werden sollen, zur (impliziten) Konvertierung genutzt wird.
Diese Einstellungen können bei Oracle (Datenbank und Client) auf verschiedenen Ebenen erfolgen. In der DB, im Client, in den NLS Settings, je Session und ich habe bestimmt noch was vergessen.

Dieser Mechanismus ist in irgendeiner ähnlichen Form sicher auch bei MSSQL möglich. Die Strecke Excel, DB Client, DB Server muss in den Settings richtig konfiguriert werden, dann sollte es auch mit MSSQL klappen (also Excel und MSSQL, wenn das nicht geht, was dann.)
Du kannst auch versuchen, die Formatierung in Excel zu ändern. Ich bin da kein Profi, aber es ist in meinen Augen sinnlos, weil es nur um die Anzeige geht und die Formatierung nichts daran ändert, dass Excel keine Typen kennt. Falls Du auf diesem Weg etwas erreichst, herzlichen Glückwunsch, ich würde mich aber nicht drauf verlassen. Im Gegenteil, gut vorstellbar, dass einfach nur alles verarbeitet wird, was in das Schema Jahreszahl, Monatszahl bis 12, Tag bis 31 oder so passt....
2 Möglichkeiten:
- Stell den Client richtig ein, davon profitiert dann jedes Programm, dass diesen Client nutzt.
- Ändere die Abfrage so, dass in der Abfrage selbst eine explizite Konvertierung von String (als String kommt das Datum rüber) zu Date, Datetime oder was es auch immer erfolgt.

Du kannst die zweite Variante auch gut zu Fuß testen und echte Datums als String übergeben und sehen, was passiert, wenn sie falsch formatiert sind, also nicht der Formatvorgabe der expliziten Konvertierung entsprechen.

Oracle Beispiel für Typ date:
where <datumsspalte> = to_date('23.09.2024', 'DD.MM.YYYY')

Für die parametrierten Abfragen müsste dann statt '23.09.2024' wieder das ? rein.
In MSSQL gibt es sicher etwas analoges mit convert oder so.

 

[ukulele]

Eine implizierte Konvertierung macht auch MSSQL. Mich irritiert viel mehr die Fehlermeldung, eventuell fehlen da einfach nur die Striche? Also '?' statt ?

 

[t-sql]

Eine implizierte Konvertierung macht auch MSSQL. Mich irritiert viel mehr die Fehlermeldung, eventuell fehlen da einfach nur die Striche? Also '?' statt ?

Deswegen soll er sich ja die Abfrage im Excel anschauen, wenns denn geht. Die Abfrage selber ist ja nicht fehlerhaft.

 

[dabadepdu]

Eine implizierte Konvertierung macht auch MSSQL

Na klar! Es geht bei impliziter Konvertierung doch nur darum, dass wenigsten beide Seiten dann (implizit, entweder zufällig oder absichtlich konfiguriert) die gleiche Annahme vom Format haben. Eine implizite Konvertierung ist m.E. niemals wünschenswert, weil es mehrere Stellen gibt, wo sich Konfigurationsunterschiede in der Kommunikation zwischen Client und Server ergeben können, am häufigsten bedingt durch unterschiedliche Sprach-/Ländereinstellungen des Betriebssystems.
Ich glaube nicht, dass Hochkommata fehlen. Die Systeme, die ich kenne nutzen eine Parameter-Symbolik unabhängig vom Datentyp. Aber ich nutze MSSQL gar nicht und Excel nicht in der Form.

Beispiel:
where menge = '5'
Hier wird '5' mit Sicherheit in jeder Datenbank implizit zu einer Zahl konvertiert, eine Ganzzahl. Es gibt niemals ein Problem.

where gewicht = '5,6'
Hier funktioniert implizite Konvertierung nur, wenn das Dezimaltrennzeichen im String den Spracheinstellung, Decimalseparator im DB Client entspricht.

Bei Datumsstrings beginnt dann die große Vielfalt der Möglichkeiten. Ein Datumsstring wie '2024-09-24', der nicht wird dann vielleicht als Subtraktion ausgerechnet, statt zu Datum konvertiert, je nach dem, was die DB für einen Default Datumsformat hat.

 

[Voosjey]

Wenn ich '?' mache, sagt er: Fehler beim Konvertieren einer Zeichenfolge in ein Datum und/oder eine Uhrzeit. Wenn ich ? eintrage sagt er diesen Fehler: Der mehrteilige Bezeichner "atko.verlade_dat_atko" konnte nicht gebunden werden.

 

[ukulele]

Wenn ich '?' mache, sagt er: Fehler beim Konvertieren einer Zeichenfolge in ein Datum und/oder eine Uhrzeit. Wenn ich ? eintrage sagt er diesen Fehler: Der mehrteilige Bezeichner "atko.verlade_dat_atko" konnte nicht gebunden werden.

Okay dann ist im ersten Fall entweder dein Datums-String falsch aufgebaut oder er ersetzt das ? nicht durch einen Wert, und ein ? kann man halt nicht in ein Datum konvertieren. Nach ein wenig Google müsste ? auch funktionieren, ohne Striche.

Teste bitte mal eine einzelne Abfrage der Spalte mit nur
WHERE atko.verlade_dat_atko = ?

 

[dabadepdu]

Wenn ich '?' mache...

Tja, irgendjemand muss wohl mal ein wenig in der Dokumentation blättern. Ich habe die Systeme nicht zur Verfügung.

Hier hab ich Beispiele für explizite und implizite Konvertierung gebaut (hoffe das geht, dbfiddle lief nicht):

42t52c69r - Microsoft SQL Server - OneCompiler

onecompiler.com

Mit expliziter Konvertierung dürfte das Problem gar nicht auftreten. (Wenn alle Datumswerte gleichformatig eingetragen sind)

 

[Voosjey]

wenn ich nur eine abfrage = ? mache kommt das gleiche Problem, dann halt nur einmal statt zwei mal, das interessante ist aber wenn ich die SQL ganz simple halte, also

select * from atko where atko.verlade_dat_atko >=? and atko.verlade_dat_atko <=?

dann funktioniert die abfrage mit derm Datum, Ohne das ich was umgestellt habe. also wo ist mein Problem bei dieser SQL. Ich sehe es nicht

 

[dabadepdu]

Ich sehe es nicht

Kommt drauf an, wo man hinschaut.
Aber Vereinfachung ist eine gute Strategie.

Mach bitte mal ein "select verlade_dat_atko, count(*) from (<einfacheAbfrageVonOben>) group by verlade_dat_atko" und versuche nach und nach größere Ranges (bis zu einem Jahr, hab grad keine Vorstellung wie groß die Tabelle ist).
Mein Tipp wäre, dass es dann wieder Fehler gibt.

Noch eine Frage: Wer hindert Dich, eine explizite Konvertierung zu versuchen?

 

[Voosjey]

die abfragen sind maximal 1,5 Monate, und mit dem direkten Datum in der großen abfrage kommt er ja auch zurecht, daher denke ich nicht das es an dem Range liegt, es muss irgendwas doch in der Syntax sein. deine Vereinfachung hatte ja auch funktioniert ohne das er das Datum anders genutzt hast, wenn die gleichen werte rausgekommen wären bei deiner Syntax und meiner, hätte ich deine Abfrage genommen.

 

[ukulele]

Dann versuch doch bitte mal:

SELECT atko.nr_atko, atko.nr_kd, kd.ku_bez_kd, atko.verlade_dat_atko, atpo.br_atpo, atpo.ho_atpo, atpo.szr1_atpo, atpo.szr2_atpo,
atpo.std_di_atpo, ar.nr_divz, atpo.me_atpo, atpokl.typ_atpokl, atpokl.nr_atposl_atpokl, ar.nr_arpg, ar.nr_arwg, ar.nr_argr, ar.nr_arty, ar.bez_ar,
atpo.monr_atpo, atpokl.bez_quell_atpokl, atpo.qm_atpo, atko.st_we_atko,atpo.ke_st_atpo, atpo.ke_sp_atpo, atpo.ke_ba_atpo, atpokl.NR_VATER_ATPOKL
FROM atko, atpo, atpokl, ar, kd
WHERE atko.fil_atko in (1,2) and
atpokl.nr_atko = atko.nr_atko and
atpokl.nr_atpo = atpo.nr_atpo and
atpo.nr_atko = atko.nr_atko and
atpokl.typ_atpokl in (1,2,3,4,10) and
atko.nr_vgart < 110 and
atko.st_atko < 120 and atko.st_atko > 101 and
kd.nr_kd = atko.nr_kd and
ar.nr_ar = atpokl.nr_ar and
atko.verlade_dat_atko >= ? and
atko.verlade_dat_atko <= ?

Das ist alles, ausgenommen die Subselects. Der wird irgendwo eine Klammer eines Subselects falsch setzen oder nicht berücksichtigen, irgendwo verschluckt er sich.

 

[Voosjey]

ohne die Subselects läuft es