Sql execute

Ich verstehe die Dokumentation zu SQL EXECUTE leider nicht ganz.

Ziel: Daten eines lokalen Datensatzes (4D Einzelplatz) sollen auf dem Server (auch 4D) erzeugt werden.

query([tabelle];[tabelle]name=“Test”)
// ein Datensatz gefunden
sql login
SQL EXECUTE(“Select tabelle.name FROM tabelle”;[tabelle]name)
SQL LOAD RECORD(SQL all records)

erzeugt alle lokalen Datensätze in der Serverdatenbank.
Auch ein SQL LOAD RECORD(1) hilft da nicht.
Ein WHERE im Select Statement wirkt auf die Remote Datenbank, geht also auch nicht.

Wie ist es richtig?

V15.3

Nebenbei: im zweiten Beispiel in der Doku http://doc.4d.com/4Dv16/4D/16/SQL-EXECUTE.301-3035989.de.html wird mit einer Transaktion gearbeitet - die Datensätze werden aber in der Remote Datenbank erzeugt, wo Validate / Cancel Transaction ja wohl nicht wirkt??

SQL LOAD RECORD macht immer einen Bind der gefundenen DS zum Zielobjekt. SELECT ohne WHERE selektiert alle DS in der Quelltabelle. SQL LOAD RECORD(n) bindet immer n Datensätze, ausgehend vom ersten DS. Mit SQL all recs bindet er immer alle. SELECT mit WHERE selektiert eine Unterauswahl in der Quelltabelle. n bindet aus dem Suchergebnis immer n DS, SQL all recs alle gefundenen, im Zweifel also nur einen. Das war so schon immer, hat sich nicht in v15 oder v16 geändert.

Das gilt nun alles lokal. Verbunden an eine externe 4D DB geht das so gar nicht. 4D versucht immer auf beide Tabellen in der gleichen Datenquelle zuzugreifen. Aber auch dann ist das Verhalten, wie lokal. Es werden in T2 immer maximal soviele DS angelegt, wie in T1 gefunden wurden.

Sie sollten hier zuerst die Daten der lokalen DB in Arrays packen, dann nach einem Login aus den Arrays in die externe DB senden.

Nebenbei sind die Befehle aus dem Kapitel SQL überholt. Es sind die alten ODBC-Befehle. Sie sollten heute nur noch mit BEGIN/END SQL arbeiten.

Die Transaktionen arbeiten in diesem Fall an der lokalen DB. Wollen Sie das anders, dann alternativ mit auto-commit in der externen DB, SELECT FOR UPDATE, oder BEGIN/END SQL.

So ganz hab ich´s noch nicht kapiert, aber ok, künftig Begin / End SQL.

Aber auch hier das Problem: 1 lokaler Datensatz in der Auswahl, gefunden mit klassischen 4D Suchbefehlen. Dann ein

insert into tabelle(Name) values (<<[tabelle]Name>>);

ignoriert die aktuelle lokale Auswahl und legt alle lokal in der Tabelle vorhandenen Datensätze in der Remote Datenbank an. Wie lege ich die lokale Auswahl fest?
OK, mit kopieren in Variablen würde es gehen, aber was bringt der Bind mit Tabellen dann? Dass man immer alle Datensätze schicken will, ist doch eher unwahrscheinlich.

Zudem würde ich mir gerne die Definition von >100 lokalen Variablen (mehrere Tabellen mit einer Anzahl von Feldern) sparen.

Am liebsten wäre mir das natürlich auch noch generisch…Und, da ich gerade beim Wünschen bin: künftig auch mit Objektfeldern. Aber den FeatureRequest gibt es ja schon.

: Markus WEBER

Am liebsten wäre mir das natürlich auch noch generisch…
http://forums.4d.fr/Post/FR/18728433/1/18728434#18728434see here>…

ich wollte damit eigentlich gesagt haben, daß in meinen Tests mit dem von Ihnen angegebenen Code nie alle Datensätze angelegt werden, sondern nur die gewünschten. Und zwar lokal oder remote. Hier mein Code:

<code 4D>
stmt:=“SELECT name FROM Table_1 WHERE name = ‘b’”
SQL LOGIN(“IP:192.168.10.111”;“Designer”;"")
//SQL LOGIN(sql_internal;"";"")
SQL EXECUTE(stmt;[Table_2]name)
SQL LOAD RECORD(SQL all records)
SQL LOGOUT

</code 4D>

Der Hinweis, in Zukunft anders zu arbeiten, hatte nichts mit der Funktionalität zu tun. Wenn Ihnen mein Beispielcode nicht hilft oder sich Ihre Programmierung anders verhält, dann senden Sie uns bitte unter support-de@4d.com eine Beispieldatenbank mit Ihrem Vorgehen zu.