Migrationsproblem Interbase -> MSSQL

[Frank Link]

Hallo Zusammenhang,
wir sind im Augenblick dabei unsere Datenbank Firebird nach MSSQL zu migrieren. (Leider möchte einer unserer Kunden den Firebird nicht einsetzen).

Bei der Umsetzung unserer Stored Procedure und Select-Anweisungen sind wir auf folgendes Problem gestossen:

gültiger Interbase-Aufruf:

SELECT * FROM EMPLOYEE, GETEMPLOYEES4PROJECT( :EmployeeID ) PROJECT
WHERE EMPLOYEE.EMPLOYEE_ID = PROJECT.EMPLOYEE_ID

GETEMPLOYEES4PROJECT ist hierbei eine Stored Procedure.

Der Aufruf erfolgt aus Delphi heraus.

Wir haben leider für MSSQL bisher noch keine Entsprechung gefunden und haben auch keine Idee mehr, wie wir weiter vorgehen können.

Unser Ziel war eigentlich, möglichst keine Änderungen am Delphi-Code vorzunehmen.

Habt Ihr ähnliche Probleme gehabt und wie konntet Ihr diese lösen.

Vielen Dank für jedes Post.

Gruß
Frank Link

[Bernhard Geyer]

Unser Ziel war eigentlich, möglichst keine Änderungen am Delphi-Code vorzunehmen.

Keine Änderungen bedeutet erst mal das ihr den DB-Zugriff in einer Unit kapselt (Stichwort: Bridge-Pattern) und dann die vorhandenen Unterschiede der DB's dort kapselt.

[Frank Link]

Hallo Bernhard,
davon sind wir ausgegangen, das Bridge-Pattern haben wir bereits implementiert. Sodaß wir die Aufrufe bereits anpassen konnten.

Aber leider verwenden wir innerhalb unserer Procedure ähnliche Konstruktionen. Was letzlich bedeuten würde, dass wir die gesamte Implementierung unser Business Logik auf Seiten der MSSQL anpassen müssen. Immerhin ca. 37000 Zeilencode.

Gruß
Frank

[hwoess]

Das oben angeführte Beispiel lässt sich durch eine Inline-Table-Funktion lösen. Funktionen können nämlich auch Tabellen zurückgeben und sind im Gegensatz zu stored procs auch im "select" verwendbar (haben dafür aber ein paar andere Einschränkungen).

Für obiges Beispiel würde das etwa so aussehen:
CREATE FUNCTION GETEMPLOYEES4PROJECT(@pid int)
RETURNS TABLE AS return select EMPLOYEE_ID from andereTabelle where PROJECTID = @pid
GO

... und das kann man dann im select so verwenden:

SELECT * FROM EMPLOYEE, dbo.GETEMPLOYEES4PROJECT(ProjectID ) PROJECT
WHERE EMPLOYEE.EMPLOYEE_ID = PROJECT.EMPLOYEE_ID

Ich nehme mal an, dass war nur ein einfaches Beispiel, sowas ist ja normalerweise ein typischer Fall für einen JOIN. Daher noch ein Hinweis: im SQL-Server lassen sich natürlich mit der Funktion auch Tabellen zurückgeben, die aus mehreren Statements erzeugt werden, als Beispiel:

CREATE FUNCTION next3values ( @val int )
RETURNS @tmp TABLE (txt varchar(10), val int ) AS
begin
insert into @tmp values ('val1',@val + 1)
insert into @tmp values ('val2',@val + 2)
insert into @tmp values ('val3',@val + 3)
return
end
GO


bye,
Helmut

[Frank Link]

Hallo Helmut,
vielen Dank für die Info. Wir haben in den letzten Tagen auch weiter geforscht und sind auf die gleiche Lösung gekommen. Leider aber auch auf ein paar Einschränkungen.

Insgesamt, sind wir von der MSSQL alles andere als begeistert s.a neues Posting

Gruss
Frank

[hwoess]

Hallo Frank,
mir geht es genau umgekehrt. Ich habe früher mit Firebird gearbeitet und hatte andauernd Probleme, vor allem öfter kaputte Datenbanken in Netzwerken mit schlechter Qualität. Nach meinem Wechsel zu MSSQL vor 6 Jahren plötzlich keine einzige kaputte Datenbank mehr, selbst bei denselben Kunden mit unverändertem Netzwerk (musste ja deswegen DB überall austauschen). Ich stehe auf MSSQL und würde keinen Wechsel mehr zurück zu Firebird machen.

bye,
Helmut

[Bernhard Geyer]

Ein DB-Wechsel (oder umstellung auf Multi-DB-Support) ist umso aufwendiger je mehr DB-Spezialitäten verwendet werden. Und jeder DB-Hersteller ist darauf bedacht möglich viele eigenheiten zu implementieren damit das Anti-Pattern Vendor-Login auch schön funktioniert.