ODBCDBE und MSSQL

[Rudolf]

Hallo,
hat jemand größerer Projekte mit der ODBCDBE gemacht ? Ich habe anfangs damit gearbeitet und hatte große Probleme. Muss ein Projekt damit machen und kann SQLEXPRESS wegen Fehler momentan nicht verwenden.
Grüße
Rudolf

[jbertram]

Ich habe wegen verschiedener Probleme mit ODBCDBE einen alternativen Ansatz für meine Projekte gebaut:
die SQL-Seite wird mit C#/Dot.Net/ADO gehandelt, das ganze als OCX/Activex verpackt und über Activex/Createobject aus Xbase++ angesprochen. Funktioniert für meinen Bedarf sehr gut und man hat m.E. mehr Kontrolle über das was geschieht und man kann zwischen man hat die Zusatzebend C#+ADO um Probleme zu lösen, also nicht nur SQL und Xbase++

Falls das interessiert kann ich gerne mehr dazu sagen, evt. einfach mal telefonieren

+49 172 6738873
+49 6173 7027591
email: joerg.bertram@t-online.de

Jörg Bertram

[Tom]

Ich mache nur kleinere Sachen (Datenabfragen, Datenmigrationen) über die ODBCDBE. Sie ist nicht verlässlich und äußerst langsam, und die Konfiguration ist für Endanwender meistens zu komplex, muss außerdem für jeden Arbeitsplatz erfolgen.

[Rudolf]

Hallo Tom, Bertram,
Danke für Eure Antworten, fühle mich bestätigt dass ich die Finger von der ODBCDBE lasse, die alten Fehler dürften immer noch nicht behoben sein. Alleine ich habe mind. 3 PDR's damals gefunden, wer weiss was da noch alles lauert
Versuche weiter mit SQLEXPRESS meine Probleme zu lösen, mit workarounds komme ich der Lösung schon näher. Aber nur die letzte autoincrement ID zurückzulesen nach eine SQL statement ist schon ein Problem bei dem nicht mal Boris helfen kann. Und habe noch Probleme mit Cursor, obwohl ich sie bei anderen Projekten problemlos einsetze. Sehe also viele Fallen in die man tappen kann, aber ich glaube das liegt grundsätzlich am SQL.
Grüße
Rudolf

[jbertram]

scope_identity()

oder meine bevorzugte variante:

insert into TabellenName(Feldname) output inserted.id_feldname_id values ('TEST')

man kann es auch wie bei xbase++ (append blank) machen: per procedur erzeugt man sich erstmal einen leeren neue Datensatz mit einer wie auch immer gearteten Nr, lässt sich diese Nr zurückgegen und macht dann auf diesen Satz ein update , also keine inserts mehr

Jörg

[Rudolf]

Hallo Jörg,
ich teste mit LAST_INSERT_ID() in MySQL und SQLEXPRESS indem ich es ans INSERT Statement anhänge. Ich weiss aber nicht wie ich den Wert wieder zurückbekomme. In der MySQL Workbench habe ich sofort die neue ID über die Kommandozeile. Mit einen SQL Cursor geht es mit fieldget(1), aber ich erhalte immer eine falsche ID da die Daten anscheinend noch nicht am Server zurückgespeichert wurden. Und wenn ich ein updaterow() mache, geht gar nichts mehr, ich dachte ich kann danach gleich die neue autoincement id auslesen. Die später mit fieldput gesetzten Werte landen dann nicht in der Tabelle. Das gleiche mit commit(). Dachte das geht mit ODBCDBE, aber ist mir jetzt grundsätzlich zu unsicher.
Grüße
Rudolf

[brandelh]

bei dbf dateien hatte ich auch nie einen autoinkrement, daher habe ich entweder aus dem Inhalt oder aus einer Zufallszahl eine eindeutige ID erstellt und diese verwendet.
Warum nicht bei SQL auch so machen ?

PS: zu MySQL hatte ich was gefunden:
http://xbaseforum.de/viewtopic.php?f=88 ... %2A#p77386

[AUGE_OHR]

so wie ich die Antwort von Boris in der Newsgroup verstanden habe muss man die Query separat durchführen um das richtige Ergebnis zu bekommen.

Error update cursor after append
sqlexpress
17. November 2016

Boris Borzic
23. November 2016

Code: Alles auswählen

function InsertGetLastID( oInsert, aParam )
   local nSuccess, nID, oConn, oCur
   if aParam == NIL
      nSuccess := oInsert:execute()
   else
      nSuccess := oInsert:execute(aParam)
   endif
   if nSuccess == SQL_XPP_ERROR
    Return -1
   endif
   oConn := oInsert:connection
   oCur := SQLSelect():new("SELECT LAST_INSERT_ID()", oConn,;
      SQL_CONCUR_READ_ONLY, SQL_CURSOR_FORWARD_ONLY)
   oCur:execute()
   nID := oCur:fieldget(1)
   oCur:destroy()
   Return nID

[Rudolf]

Hallo Jimmy,
danke hab ich schon so gemacht, aber natürlich sehr umständlich und langsam sowas nach jedem SQL Statement auszuführen. Ich dachte es gibt eine Lösung bei der man beim Abschicken des Statements sofort die ID zurückbeommt.
Grüße
Rudolf

[jbertram]

Wenn du das nicht als xbase++ Funktion sondern als SQL-Procedur ausführst, dann hättest du nur einen SQL-call

[Rudolf]

Hallo Jimmy,
anscheinend kann ich Rückgabewerte nur über eine Cursor holen, sonst hätte ich auch schon an ein Script gedacht. Das Problem ist dass man keinen Rückgabewert für ein SQL Statement bekommt sondern immer nur den Status bzw. rows effected.
Grüße
Rudolf

[georg]

Hallo,


bei MySQL gibt es eine Funktion, Last_Insert_ID(). Die liefert die zuletzt erstellte ID (AUTO_INCREMENT) zurück.

Ich gehe stark davon aus, dass es bei MSSQL eine vergleichbare Funktion gibt.

[Rudolf]

Hallo Georg,
die kenne ich, in SQLEXPRESS gibt es auch:

:LastIDSyntax
exported / character
Provides the SQL SELECT syntax for retrieving the last inserted identity value from a table containing a auto-unique field.

Example:
oConn:LastIDSyntax := "SELECT SCOPE_IDENTITY()" // MS-SQL Server syntax

Aber auch Boris hat keine Lösung, nur diese hier:

Code: Alles auswählen

function InsertGetLastID( oInsert, aParam )
******************************************************************
local nSuccess, nID, oConn, oCur
if aParam == NIL
   nSuccess := oInsert:execute()
else
   nSuccess := oInsert:execute(aParam)
endif
if nSuccess == SQL_XPP_ERROR
         Return -1
endif
oConn := oInsert:connection
oCur := SQLSelect():new("SELECT LAST_INSERT_ID()", oConn,;
   SQL_CONCUR_READ_ONLY, SQL_CURSOR_FORWARD_ONLY)
oCur:execute()
nID := oCur:fieldget(1)
oCur:destroy()
Return nID

Wie Du siehst sehr umständlich und zeitaufwändig wenn man viele Sätze bearbeitet.

Grüße
Rudolf

[georg]

Hallo, Rudolf -


ich habe es nicht ausprobiert, denke aber, dass es so gehen könnte:

Code: Alles auswählen

cStmt := "INSERT INTO ...; SELECT last_insert_id();"

Das Ganze dann als Query ausführen (auch ein INSERT ist ein Query).

Ob ODBCDBE Dir dann das Ergebnis der zweiten Anweisung richitg zurückliefert, das kann ich nicht sagen, das müsstest Du ausprobieren.

[Rudolf]

Hallo Georg,
genau das habe ich schon probiert, bekomme die ID nicht zurück, nur den Fehlerstatus. Man muss in SQLEXPRESS 3 sogar :LastIDSyntax = NIL setzen, sonst kommt ein Fehler. Ich denke dass Boris hier schon experimentiert hat, aber noch keine Lösung.
Grüße
Rudolf

[Rudolf]

Hallo,
vielleicht bestätigt das meine Befürchtungen dass es nicht möglich ist:

Fetching the last id after an insert is a terrible waste of server
resources if you do not need it. And quite often it is not needed,
therefore I will not be adding this to the library. However, you can do it
yourself very easily, example (untested code):

Für mich unverständlich, SQL dürfte in vielen Bereichen ein Problem werden im Vergleich zu DBF Dateien.

Grüße
Rudolf

[georg]

Hallo, Rudolf -


ich kenne Dein Problem nicht genau, aber ich würde mir persönlich überlegen, wie ich den Datensatz so "eindeutig" machen kann, dass man ihn wieder auffinden kann.

So führe ich in fast allen Tabellen ein TIMESTAMP-Feld mit, um auf einfache und schnelle Art konkurrierende Updates zu erkennen.

Ein "SELECT now() AS TIMESTAMP;" vor dem INSERT und eines nach dem INSERT liefert mir den Zeitrahmen, in dem mein INSERT ausgeführt wurde. Wenn die Tabelle nun noch den Benutzer und die Workstation als Felder enthält, sollte es möglich sein, den gerade geschriebenen Satz zu identifizieren:

Code: Alles auswählen

SELECT record_id FROM table WHERE timestamp >= " + cTS1 + " AND timestamp <= " + cTS2 + " AND username = '" + cUserName + '" AND workstation = '" + cWorkstation + "'"

Es ist nicht zwingend elegant, es ist nicht zwingend schnell, es frisst zusätzlichen Speicherplatz durch die Felder für Benutzer, Workstation und den Timestamp, aber es sollte den gerade geschriebenen Satz so isolieren können, dass Du an den primary key rankommst.

[Rudolf]

Hallo Gerog,
könnte es so machen, habe auch dtos(date())+ntrim(sconds()) als ID, aber denke es ist genauso langsam wie über den Cursor. Werde es aber mal teste, 1000 mal über last insert id und mit Deiner Methode, mal schauen wie groß der Unterschied ist. Habe große Unterschiede zwischen Cursor und SQL Statements gefunden die alles extrem langsam machen können.
Grüße
Rudolf