insert into select from mit ID als IDENTITY

[Andreas Wohlmuth]

Hallo

wie ist der Beste weg hier keinen Fehler zu bekommen. Kann man die ID der Source-Tabelle mit einem Trigger auf NULL setzen oder so ?

[Andreas Kosch]

Hallo,

so richtig verstehe ich die Frage nicht. Beim Füllen der Zieltabelle kann man die IDENTITY-Spalte der Quelltabelle ja ausblenden:
<pre>
USE tempdb
GO
-- Quelltabelle
CREATE TABLE SourceTbl (
RecID INTEGER NOT NULL IDENTITY PRIMARY KEY,
Wert VARCHAR(5) NOT NULL)
GO
INSERT INTO SourceTbl (Wert) VALUES ('Wert1')
INSERT INTO SourceTbl (Wert) VALUES ('Wert2')
INSERT INTO SourceTbl (Wert) VALUES ('Wert3')
GO
-- Zieltabelle
CREATE TABLE TargetTbl (
RecID INTEGER NOT NULL IDENTITY PRIMARY KEY,
Wert VARCHAR(5) NOT NULL)
GO
-- Daten einfügen
INSERT INTO TargetTbl
SELECT Wert FROM SourceTbl
-- Ergebnis prüfen
SELECT * FROM TargetTbl
</pre>
Wenn es aber darum geht, dass die Zieltabelle trotz IDENTITY-Kennzeichnung die "alten" Werte der Quell-Tabelle verwenden muss, steht die <b>SET IDENTITY_INSERT <i>Tabelle</i> ON</b>-Anweisung zur Verfügung

[Andreas Wohlmuth]

Hallo

entschuldigung, hatte vergessen zu erwähnen das die Tabelle 74 Felder besitzt. Zum Teil lese ich die Tabellesnstruktur ab dem zweiten Feld aus und erzeuge mir so die Inserts. Aber ich hoffe das es da vieleicht eine bessere Alternative gibt. Ich möchte einfach einen Datensatz von einer Tabelle in die Andere kopieren (Stornodatensatz), dabei soll aber eine neue ID vergeben werden. Mit insert into select * from bekomme ich den Fehler das ich keinen Wert in ein IDENTITY Feld eintragen darf.

Gibts einen Nachfolger von Client/Server Datenbankentwicklung bzw. sind in der Ausgabe von 1999 die Konzepte noch gültig, dann werd ich's mir mal holen. Auch gut wäre ein Buch über: wie Pflege ich ein vorhandenes Programm/DB weiter. Denn eine Tabelle mit 74 Datensätze dürfte doch eigentlich nicht vorkommen ,oder

[Andreas Kosch]

Hallo,

&gt;Mit insert into select * from ...

Generell ist <i>SELECT *</i> wohl nur in Demo-Anwendungen angebracht, bei denen der Blick auf das Wesentliche nicht durch vermeidbare Details verborgen werden soll. In einer richtigen Anwendung sollte man darauf verzichten und die Spalten der Ergebnismenge in der "richtigen" (vom Client erwarteten) Reihenfolge aufzählen.

Wenn es darum geht, das manuelle Eintippen alle Spaltennamen zu vermeiden, kann man ja zu Tools greifen, die so etwas automatisch machen (wie zum Beispiel die IDE von <i>Visual Studio.NET</i>, die <i>Datenbankoberfläche</i> von Borland oder das Abfrage-Tool von Microsoft Access).

&gt;Denn eine Tabelle mit 74 Spalten dürfte doch eigentlich nicht vorkommen ,oder?

So pauschal würde ich das nicht ausdrücken - solange diese Tabelle trotzdem in der dritten Normalform ist, besteht kein dringender Handlungsbedarf. Denn bei einer korrekt normalisierten Tabelle besteht die einzige Alternative in der Auslagerung in 1:1-Tabellen - wobei dies spätestens dann zum Nachteil würde, wenn der Client häufig alle Spalten in einer SELECT-Ergebnismenge benötigt.

&gt;.. Ausgabe von 1999 die Konzepte noch gültig...

Alle Aussagen zum Datenbank-Design sind noch gültig - derartige Informationen haben eine sehr lange Halbwertszeit (solange nicht eine völlig neue und vor allem bessere Threorie das Licht der Welt erblickt, die dann auch von den Datenbank-Herstellern umgesetzt werden müsste)

[Andreas Wohlmuth]

Hallo,

wiederum Danke für die Tipps.
Das select * from werde ich dann mal weglassen :-) Kann man den SQL-Builder von TQuery noch irgendwie benützen ( ohne TQuery), der war wirklich gut bzw. gibts den als eigenständiges Produkt ?

[Andreas Kosch]

Solange sich die generierte SELECT-Anweisung in die Zwischenablage kopieren lässt, ist <b>alles</b> geeignet :-