Arbeiten mit INSERT INTO

Nachtschrat · Beiträge: 16

Hallo zusammen,
ich habe ein kleines Problem mit INERT INTO. Ich will aus Tabelle2 Daten in Tabelle1 kopieren und scheitere an der Syntax.
Es geht um PARADOX-Datenbanken

Versucht habe ich es - wie im Netz gefunden - mit:

markieren

SQL-Anweisung

1:
2:
3:

INSERT INTO Tabelle1 (Spalte1, Spalte2)
SELECT Spalte2, Spalte3
FROM Tabelle2

Was läuft hier schief? Ich bin echt am Ende mit meinem Latein. Er meldet immer und immer wieder, dass Spalte2 und Spalte3 nicht existieren - das tun sie aber - und zwar in Tabelle 2. In Tabelle 1 jedoch nicht. Da sollen die Daten halt in eine andere Spalte.

Danke schonmal für die Hilfe und ich hoffe es ist verständlich

Moderiert von Klabautermann: Delphi durch SQL-Tags ersetzt.

mkinzler · Verfasst: Di 24.07.07 18:42

Grundsätzlich sollte es eigentlich so gehen, aber versuchs mal mit roe renaming:

markieren

SQL-Anweisung

1:
2:
3:

INSERT INTO Tabelle1 (Spalte1, Spalte2)
SELECT Spalte2 as Spalte1, Spalte3 as Spalte2
FROM Tabelle2;

_________________
Markus Kinzler.

ene · Verfasst: Mi 25.07.07 06:02

Sind die Felder auch vom gleichen Datentypen?

_________________
Wir, die guten Willens sind, geführt von Ahnungslosen, Versuchen für die Undankbaren das Unmögliche zu vollbringen.
Wir haben soviel mit so wenig so lange versucht, daß wir jetzt qualifiziert sind, fast alles mit Nichts zu bewerkstelligen.

jasocul · Verfasst: Mi 25.07.07 11:23

Nachtschrat hat folgendes geschrieben:

Versucht habe ich es - wie im Netz gefunden - mit:

markieren

Delphi-Quelltext

1:
2:
3:

INSERT INTO Tabelle1 (Spalte1, Spalte2)
SELECT Spalte2, Spalte3
FROM Tabelle2

Er meldet immer und immer wieder, dass Spalte2 und Spalte3 nicht existieren - das tun sie aber - und zwar in Tabelle 2. In Tabelle 1 jedoch nicht. Da sollen die Daten halt in eine andere Spalte.

Sicher, dass die Spalten existieren? Paradox reagiert zwar manchmal etwas merkwürdig, was SQL betrifft, aber theoretisch sollte Deine Anweisung funktionieren. Probiere doch mal, ob an der Stelle im Programm das Select-Statement alleine funktioniert.

@mkinzler:
Alias-Namen für Felder sind in Paradox beim Data-Manipulating meines Wissens unzulässig.

@ene:
Dann sollte eine andere Fehlermeldung kommen.

Nachtschrat · Beiträge: 16

Ja, die Felder haben den selben Typ. Mal ne Frage nebenbei - die Felder muss ich nicht im Query hinzufügen oder?

Das SELECT-Statement alleine funktioniert auch nicht - selber Fehler.

Ich weiß nicht weiter - nicht mal das Einfügen in eine 'baugleiche' Datenbank - also 1:1 nur leer - will er mir füllen.

Mal eine Nebenfrage: Wie sage ich SQL, er soll die Daten aus der Zeile nehmen wo der Datenzeiger steht?

jasocul · Verfasst: Do 26.07.07 11:55

Nachtschrat hat folgendes geschrieben:

Das SELECT-Statement alleine funktioniert auch nicht - selber Fehler.

Dann existieren Spalte1 und/oder Spalte2 dort auch nicht. Da gibts nichts dran zu rütteln.

Nachtschrat hat folgendes geschrieben:

Mal eine Nebenfrage: Wie sage ich SQL, er soll die Daten aus der Zeile nehmen wo der Datenzeiger steht?

Bin zwar kein Mod mehr, aber: Neue Frage -> Neuer Thread.

Nachtschrat · Beiträge: 16

jasocul hat folgendes geschrieben:

Nachtschrat hat folgendes geschrieben:

Das SELECT-Statement alleine funktioniert auch nicht - selber Fehler.

Dann existieren Spalte1 und/oder Spalte2 dort auch nicht. Da gibts nichts dran zu rütteln.

Nachtschrat hat folgendes geschrieben:

Mal eine Nebenfrage: Wie sage ich SQL, er soll die Daten aus der Zeile nehmen wo der Datenzeiger steht?

Bin zwar kein Mod mehr, aber: Neue Frage -> Neuer Thread.

Hättest du den unteren teil weiter gelesen, dann hättest du dir diesen Post sparen können :roll:

Nachtschrat hat folgendes geschrieben:

Das SELECT-Statement alleine funktioniert auch nicht - selber Fehler.

Ich weiß nicht weiter - nicht mal das Einfügen in eine 'baugleiche' Datenbank - also 1:1 nur leer - will er mir füllen.

jasocul · Verfasst: Do 26.07.07 13:47

Doch, habe ich gelesen. Es nützt nur nichts, wenn Du eine baugleiche Tabelle erstellst, wenn schon die Abfrage aus der Ursprungstabelle nicht funktioniert.

Du musst erstmal heraus bekommen, warum das Select-Statement nicht läuft. Ursachen kann es viele geben. Probier doch man ein Select * from Tabelle2. Am besten lässt Du Dir die Daten noch in einem DBGrid anzeigen. Dort bekommst Du auch die Feld-Namen angezeigt. Könnte ja sein, dass Du mit persistenten Feldern (Mein Hass-Thema) irgendwo arbeitest. Das kann so einiges durcheinander bringen. Allerdings in der von Dir beschriebenen Situation wüsste ich nicht, wie.

Wie gesagt: Löse erst mal das Problem mit dem Select, bevor Du Dich weiter um das Insert kümmerst.

Nachtschrat · Beiträge: 16

SELECT * FROM funktioniert.
Ich habe gestern nochmal ein wenig rumprobiert und habe ihm eine neue Fehlermeldung entlockt: "Fehler beim Erstellen des Cursor-Handle". Kann mir da zufällig jemand sagen, was er von mir will? Die Meldung hatte ich noch nie.

Danke schonmal

Ach und äh jasocul, ich wollte dich da nicht blöd anmachen oder so. War nur an dem Tag etwas überladen und das war vielleicht eine Überreaktion. Bin echt dankbar für jede Hilfe!

jasocul · Verfasst: Sa 28.07.07 17:13

Nachtschrat hat folgendes geschrieben:

SELECT * FROM funktioniert.

Und hast Du die Feldnamen nochmal geprüft? Ansonsten probiere es nochmal mit einem völlig neuen TQuery-Objekt, dass keine weiteren Einstellungen außer dem absolut notwendigen hat. Also keine Verbindung zu einem TDataSource, etc. Vielleicht machst Du für genau diese Sache ein kleines Mini-Programm, damit Du ganz sicher keine unbekannten Fehler mitschleppst.

Nachtschrat hat folgendes geschrieben:

Ich habe gestern nochmal ein wenig rumprobiert und habe ihm eine neue Fehlermeldung entlockt: "Fehler beim Erstellen des Cursor-Handle". Kann mir da zufällig jemand sagen, was er von mir will? Die Meldung hatte ich noch nie.

Ich nehme an, Du greifst über die BDE auf die Tabellen zu. Ohne es jetzt genau prüfen zu können, vermute ich, dass die Tabelle noch geöffnet ist (z.B. durch Programmabbruch o.ä.). Oder die Tabelle ist exclusiv geöffnet oder ... . Es gibt da viele Möglichkeiten.

Nachtschrat hat folgendes geschrieben:

Ach und äh jasocul, ich wollte dich da nicht blöd anmachen oder so. War nur an dem Tag etwas überladen und das war vielleicht eine Überreaktion. Bin echt dankbar für jede Hilfe!

Kein Problem. Das geht wohl jedem Programmierer mal so. Und Du hättest ja vielleicht auch Recht haben können. Ich habs auch nicht böse aufgefasst. Das lässt sich nur nicht in Schriftform darstellen. :wink:

BeaTBoxX · Hält's aus hier Beiträge: 9

die DB kann aber generell subselects handhaben oder?

das kann naemlich nicht jede !!

_________________
Nürnberg ist die geheime Welthautpstadt der Musik, das weiss nur noch keiner

Nachtschrat · Beiträge: 16

jasocul hat folgendes geschrieben:

Nachtschrat hat folgendes geschrieben:

SELECT * FROM funktioniert.

Und hast Du die Feldnamen nochmal geprüft? Ansonsten probiere es nochmal mit einem völlig neuen TQuery-Objekt, dass keine weiteren Einstellungen außer dem absolut notwendigen hat. Also keine Verbindung zu einem TDataSource, etc. Vielleicht machst Du für genau diese Sache ein kleines Mini-Programm, damit Du ganz sicher keine unbekannten Fehler mitschleppst.

Nachtschrat hat folgendes geschrieben:

Ich habe gestern nochmal ein wenig rumprobiert und habe ihm eine neue Fehlermeldung entlockt: "Fehler beim Erstellen des Cursor-Handle". Kann mir da zufällig jemand sagen, was er von mir will? Die Meldung hatte ich noch nie.

Ich nehme an, Du greifst über die BDE auf die Tabellen zu. Ohne es jetzt genau prüfen zu können, vermute ich, dass die Tabelle noch geöffnet ist (z.B. durch Programmabbruch o.ä.). Oder die Tabelle ist exclusiv geöffnet oder ... . Es gibt da viele Möglichkeiten.

Nachtschrat hat folgendes geschrieben:

Ach und äh jasocul, ich wollte dich da nicht blöd anmachen oder so. War nur an dem Tag etwas überladen und das war vielleicht eine Überreaktion. Bin echt dankbar für jede Hilfe!

Kein Problem. Das geht wohl jedem Programmierer mal so. Und Du hättest ja vielleicht auch Recht haben können. Ich habs auch nicht böse aufgefasst. Das lässt sich nur nicht in Schriftform darstellen. :wink:

Ich weiß es nicht ob die Tabelle noch geöffnet ist. Ich greife nur über eine DataSource und ein Query drauf zu - mehr nicht. Achso, was mir da gerade einfällt, ich habe wenn ich den Database Desktop öffne die DB noch offen - auch wenn ich das Programm beendet hatte. Kann es sein das es daran liegt? Ich habe die DB leider nicht da und kann es akut nicht überprüfen. Das wäre das einzige was mir dazu einfällt. sonst ist die DB nicht aktiv - sie wird eben nur durch das Query angesprochen. SELECT * FROM geht im Übrigen problemlos.

Was zum Deibel ist denn ein Subselect? Das höre ich nun zum ersten Mal. Je mehr ich höre desto mehr zweifel ich an der Kompetenz meines Buches :roll:

.

agent_x · Beiträge: 62 WIN 2000, Linux Kubuntu 6.06

wo soll den des insert into überchaupt stehen?

jasocul · Verfasst: Mo 13.08.07 06:53

Nachtschrat hat folgendes geschrieben:

ich habe wenn ich den Database Desktop öffne die DB noch offen - auch wenn ich das Programm beendet hatte. Kann es sein das es daran liegt?

Kann durchaus sein. Probiere es einfach aus.

Nachtschrat hat folgendes geschrieben:

Was zum Deibel ist denn ein Subselect? Das höre ich nun zum ersten Mal. Je mehr ich höre desto mehr zweifel ich an der Kompetenz meines Buches :roll:

.

Subselect spielt an dieser Stelle keine Rolle. Ein Subselect ist zum Beispiel:

markieren

SQL-Anweisung

1:
2:

select * from tabelle_1
where feld_x in (select feld_von_anderer_tabelle from anderer_tabelle)

Nachtschrat · Beiträge: 16

Nein, funtioniert leider beides nicht. Weder Schließen im DBDesktop noch funktioniert eine neue Querykomponente. Ich verstehe das nicht.

[quote=" user profile icon

jasoculSubselect spielt an dieser Stelle keine Rolle. Ein Subselect ist zum Beispiel:

markieren

SQL-Anweisung

1:
2:

select * from tabelle_1
where feld_x in (select feld_von_anderer_tabelle from anderer_tabelle)

[/quote]
Ah, alles klar. Gut zu wissen

Nachtschrat · Beiträge: 16

Nein, funtioniert leider beides nicht. Weder Schließen im DBDesktop noch funktioniert eine neue Querykomponente. Ich verstehe das nicht.

[quote=" user profile icon

jasoculSubselect spielt an dieser Stelle keine Rolle. Ein Subselect ist zum Beispiel:

markieren

SQL-Anweisung

1:
2:

select * from tabelle_1
where feld_x in (select feld_von_anderer_tabelle from anderer_tabelle)

[/quote]
Ah, alles klar. Gut zu wissen

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme