Umstieg von MS-SQL auf PG, was kommt an möglichen Problemen?

Beides ist nicht Teil des SQL Standards.

In Postgres könntest Du noch die Standard konforme Variante fetch first .. rows only verwenden.

Yupp, habs schon gemerkt. Die “fetch first…” Methode ist allerdings wiederum nicht MSSQL-konform…

Zum Glück ist unser System so aufgebaut, dass es eine zentrale Stelle gibt, welche datenbankabhängig solche und weitere Sachen regelt. Es gibt halt dann immer wieder “switch …” Stellen im Code, wo man dann eingreifen muss. Unsere SELECT-Befehle verwenden zum Beispiel noch die Syntax “SELECT X AS [Y]”, was noch auch nicht geht. So kämpfe ich mich halt durch.

Das größte Problem war gestern das Thema mit den Gänsefüßchen, aber da habt ihr mir gut auf die Sprünge geholfen. :+1:

So, nun komme ich langsam ans Eingemachte, nämlich direkte SQL-Strings im Code. Das ist kein schöner Stil, ich weiß, aber vorerst nicht zu ändern.

Bislang haben wir mit folgendem Code in eine Tabelle Datensätze eingefügt. Dabei habe ich den Code auf die Spalte mit dem Typ früher “DateTime”, jetzt “timestamp” gekürzt.

Sowas ging früher:

INSERT INTO BS_Logging (Datum) VALUES (CONVERT(DATETIME,'2021.09.22 15:35:50',120))

Nun dachte ich, sowas müsste jetzt gehen:

INSERT INTO BS_Logging (Datum) VALUES (CONVERT(timestamp,'2021.09.22 15:35:50',120))

Es geht natürlich nicht, obwohl ich den CONVERT-Befehl für gültiges SQL halte. Die Spalte “Datum” der Tabelle ist vom Typ “timestamp without time zone”. Die Fehlermeldung lautet “Spalte »timestamp« existiert nicht”.

Wie wäre es denn richtig? (Bitte nicht den Tipp mit einem sauberen Command-Objekt und Parametern, ich weiß, das wäre der exakt richtige weg, aber aus Zeitgründen muss es erst mal so gehen).

Gruß, Karsten.

Du wirst das umschreiben müssen, und to_timestamp nutzen:

edb=*# select to_timestamp('2021.09.22 15:35:50','yyyy.mm.dd hh24:mi:ss');
      to_timestamp      
------------------------
 2021-09-22 15:35:50+02
(1 row)

edb=*# 


Ja wunderbar, du hast dir damit einen Platz in meinem Abendgebet gesichert :slight_smile:
Klappt astrein, danke und schönen Feierabend.

Gruß, Karsten.

1 „Gefällt mir“

Hallo mal wieder,

ich komme jetzt tatsächlich zu dem am Anfang beschriebenen Problem, nämlich der Groß- und Kleinschreibung. Ein in der DB abgelegter Datensatz mit der Spalte “Nachname” und dem Inhalt “Heimer” wird tatsächlich in einem WHERE nur mit “WHERE Nachname='Heimer” gefunden, nicht mit “WHERE Nachname=‘heimer’”.

Kann man dieses Verhalten generell konfigurieren? Oder muss man tatsächlich im WHERE etwas anpassen?

Gruß, Karsten.

Ich antworte mir mal selber. Gemäß diesem Thread hier:
https://stackoverflow.com/questions/7005302/how-to-make-case-insensitive-query-in-postgresql
wird ILIKE als Operator empfohlen. Spricht das was dagegen?

Du kannst andere Operatoren verwenden wie ilike oder ~~*.

Du kannst auch einen funktionalen Index verwenden:

Du könntest Dir auch eine Case-Insensitive Collation anlegen, (und die Collation für die Spalten ändern oder beim Vergleich mit angeben) oder den citext Datentyp verwenden

Hallo castorp,

danke Dir. Ich habe jetzt den “ilike” Operator eingebaut. Da wir für den Datenbankzugriff eine eigene Codeschicht haben, welche zwischen den unterstützten Datenbanken unterscheidet, ist es einfach, “like” oder “ilike” zu verwenden.

Gruß, Karsten.

Hallo,

ich muss doch noch mal was fragen: Dieses SQL-Statement hier wirft einen Syntaxfehler. Bisher lief das im MSSQL durch. Ich komme einfach nicht drauf, wie ich das umformulieren muss:

IF EXISTS (SELECT Name FROM sysindexes WHERE Name = 'B4IND_WWAUFTRPOSUMUF') DROP INDEX WW_AUFTRAGPOSITIONEN.B4IND_WWAUFTRPOSUMUF

In SQL gibt es kein IF, nur in prozeduralen Sprachen wie PL/pgSQL.

In Postgres brauchst Du aber kein IF, dafür gibt es die Option IF EXISTS

drop index if exists WW_AUFTRAGPOSITIONEN.B4IND_WWAUFTRPOSUMUF;

Ah, gut zu wissen, hab’s gleich eingebaut.

Bisher dachte ich immer, die MSSQL-Statements sind eine gute Basis für PG, weil reines SQL… weit gefehlt wie mir scheint…

Gruß, Karsten.

Es gibt wohl wenig Datenbanken die weiter weg sind vom SQL Standard als SQL Server

So, da bin ich nochmal. Ich stolpere gerade über das DELETE FROM-Kommando, in Zusammenhang mit einer SubSelect-Klausel.
Bisheriger Code funktionierte unter dem SQL-Server:

"DELETE FROM FB_VZKKKontenMWWaeh FROM ((FB_VZKKKontenMWWaeh AS T504 LEFT OUTER JOIN FB_VZKKKontenMW AS T503_0 ON T504.VZKKWertID=T503_0.ID)LEFT OUTER JOIN FB_Buchungsperioden AS T378_1 ON T503_0.PeriodeID=T378_1.ID) WHERE (((T378_1.MandantID=4000000000000000010)))"

Ich kriege einfach den passenden Code für Postgre nicht hin. Ständige endet es in irgenwelchen Syntaxfehlern… Wer kann mit denn das Brett vor dem Kopf wegnehmen, irgendwas übersehe ich doch hier…

Ich kenne diese Syntax nicht, weiß also nicht so genau was genau das Statement macht. Aber kannst Du das nicht mit einer EXISTS Bedingung machen?

DELETE FROM FB_VZKKKontenMWWaeh AS T504
where exists (select * 
			  from FB_VZKKKontenMW AS T503_0 
				JOIN FB_Buchungsperioden AS T378_1 ON T503_0.PeriodeID = T378_1.ID 
			  WHERE T504.VZKKWertID = T503_0.ID
				AND T378_1.MandantID = 4000000000000000010)

P.S.: Die “Kurzform” von PostgreSQL ist Postgres, nicht “Postgre”

Hallo castorp,

danke für deinen Tipp, genau so funktioniert es…

Hinweis mit “Postgres” ist angekommen, ich werde es beherzigen :slight_smile:

Gruß, Karsten.

Dieses Thema wurde automatisch 60 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Antworten mehr erlaubt.