Von IB nach MS-SQL

[Andreas Horlaender]

Hallo, <br>
Ich möchte ein vorhandenes IB Projekt nach MS SQL-Server (2000) umstellen, zugriff über D5 ADO.<br>
Folgende Punkte interessieren mich:<br>
<ul>
<li> Ich muss die Datenbank irgendwie erzeugen, bei IB war das kein Problem da das GDB File ja nur mitgeliefert werden musste</li>
<li> Gibt es im MS-SQL so was wie Generatoren? </li>
<li> Gibt es Date und Time Felder wie in IB Dialect 3 ? </li>
<li> Kann mir jemand ein Syntax Beispiel (MS-SQL) für eine StoredProcedure für ein typisches Insert geben ? (Ein Programmteil erledigt das Insert nur über SPs) </li>
<li> Gibt es Execute Procedure() Returning Values wie bei IB </li>
</ul>
<p>Uff</p>
<p> Es gibt da noch viele andere Fragen aber Andreas Koschs ADO Buch ist noch nicht geliefert und ich bin furchtbar ungeduldig </p>
Gruß Andreas

[Andreas Kosch]

Hallo,

zu Frage 1: <br>
Der MS SQL Server bietet viele Optionen, wie eine Datenbank ausgeliefert werden kann: <br>
a) binäre Datenbankdateien ausliefern und vor Ort einhängen (macht das Connection-Objekt bzw. TADOConnection von ADO auf Wunsch automatisch)<br>
b) SQL-Script vor Ort ausführen lassen <br>
c) Datenbank-Backup vor Ort wiederherstellen<br>
Der MS SQL Server ist über seine DMO-Objekte (COM-Objekte) vollständige fernbedienbar, d.h. alles das, was der Enterprise Manager über die Benutzeroberfläche zur Verfügung stellt, kann aus dem eigenen Delphi-Programm aus ebenfalls aufgerufen werden.

zu Frage 2: <br>
Das Gegenstück zu den Generatoren ist das IDENTITY-Attribut :
<pre>
CREATE TABLE Test (
RecID INTEGER NOT NULL IDENTITY PRIMARY KEY)
</pre>

zu Frage 3: <br>
Der MS SQL Server unterstüt DATETIME und SMALLDATETIME - eine Auftrennung nach Datum und Zeit erfolgt auf Wunsch beim Aufrufen der Daten.

zu Frage 4: <br>
Die folgende Beispiel-Stored Procedure prüft über die EXISTS-Abfrage nach, ob es bereits einen Datensatz mit dieser Bankleitzahl gibt. Wenn nicht, so muss der neue Datensatz über INSERT eingefügt werden. Findet EXISTS jedoch einen Datensatz, so darf die Stored Procedure kein INSERT durchführen, sondern muss statt dessen zum UPDATE greifen. Über die Systemvariable @@ROWCOUNT prüft die Stored Procedure nach, ob auch jedesmal ein Datensatz betroffen war. War alles in Ordnung, liefert die Stored Procedure im Fall a) beim INSERT den Wert 1 zurück, ober im Fall b) beim UPDATE den Wert 2. Erhält der Aufrufer allerdings den Rückgabewert 0, war irgend etwas nicht in Ordnung.
<pre>
CREATE PROCEDURE stprUpdateBLZ
@sBLZ VARCHAR(8),
@sORT VARCHAR(50) = NULL,
@sBANK VARCHAR(50) = NULL
AS
DECLARE @iMode INTEGER
SET NOCOUNT ON
SET @iMode = 0
IF NOT EXISTS (SELECT * FROM BLZ b WHERE b.BLZ = @sBLZ)
BEGIN
INSERT BLZ (BLZ,Ort,Bank)
VALUES (@sBLZ,@sORT,@sBANK)
IF @@ROWCOUNT = 1
SET @iMode = 1
END
ELSE
BEGIN
UPDATE BLZ SET
Ort = @sORT,
Bank = @sBANK
WHERE BLZ = @sBLZ
IF @@ROWCOUNT = 1
SET @iMode = 2
END
SET NOCOUNT OFF
RETURN @iMode
</pre>

zu Frage 5: <br>
Der MS SQL Server 2000 unterstützt neben den Stored Procedures auch die Funktionen, die ebenfalls Rückgabewerte bzw. komplette Ergebnismengen zurückliefern können

[Andreas Horlaender]

Vielen Dank Andreas,<br>
ich weis schon warum ich demnächst das 5. Buch von Dir mein eigen nennen darf.<br>Gruß Andrea