Seite 1 von 1

Updaten einer MS-SQL-Server-Tabelle per ODBC ????

Verfasst: Do, 04. Mai 2006 11:55
von Pope
Hallo Leute,

ich bin kein großer SQL-Fachmann und brauche mal ein paar schnelle Tips. Ich hab mir jetzt zwar SQLExpress pro gekauft - aber da muß ich mich erst "reinwurschteln".

Also: bisher greife ich (mit xBase 1.82 und der ODBCDBE) lesend auf einige Tabellen eines SQL-Servers zu. Das funktioniert gut.

Jetzt sollte ich auch Sätze anhängen oder updaten können. Aber obwohl ich alle Rechte in einer speziell für mich gebastelten Tabelle habe und die Tabelle ganz einfach ist (nur Textfelder, keine Indizes oder gar unique), kann ich mit der klassischen variante

DbAppend()
replace name with "meier"
dbCommit()

nichts in der Tabelle erreichen.

Auch wenn ich o.g. einbette in

BEGIN Sequence
...
END Sequence

und auch noch einen ErrorBlock mit RECOVER-bsatz definiere, schaffe ich es nicht die Tabelle zu aktualisieren.

Hat mir da jemand einen schneller Tip - außer "versuchs mal mit SQLExpress - was ich mittelfristig sicher tun werde.

Danke und Gruß
Klaus

Verfasst: Do, 04. Mai 2006 12:17
von andreas
Hallo Klaus,

ich habe auch Anwendungen am Laufen die direkt über ODBC mit XBase-Mitteln zugreifen.
Mit dem Schreiben habe ich auch das gleiche Problem gehabt.
Da ich keine andere Lösung gefunden habe, sende ich den Update-Befehl mit Hilfe des SQL-Befehls von Alaska.

Code: Alles auswählen

#include "sqlcmd.ch"
...
SQL "Update ..."
Dafür muss natürlich ein Feld mit eindeutigen Werten vorhanden sein.
Damit ich nicht jedes mal das gleiche machen muss, um die Befehle aufzubauen, habe ich mir eine Classe geschrieben, die beim Initialisieren die Verbindung aufbaut und die Methoden zum Abrufen oder Updaten der SQL-Daten hat. Die für Befehlaufbau benötigte Daten werden als Parameter an die Methoden übergeben.

Verfasst: Do, 04. Mai 2006 12:36
von Tom
Mmh.

Ich habe gerade gesucht, da ist tatsächlich eine funktionierende Stelle in irgendeiner Replikationsroutine, an der wir eine SQL-Tabelle per ODBCDBE öffnen, per DbLocate() suchen (!) und dann mit REPLACE ersetzen. Wie gesagt, funktioniert einwandfrei. Sieht in etwa so aus:

Code: Alles auswählen

cConnect := "DBE=ODBCDBE;DSN=" + cDriver + ";UID="+cSqluser+";PWD="+cSqlpw+";DBQ=" + cDatabase
oSession := dacSession():new(cConnect)

IF !oSession:isConnected()
    MsgBox( oSession:getLastMessage(), "Keine Verbindung m”glich zu: " + cConnect)
    RETURN
ENDIF
select 0
USE Klienten ALIAS kli VIA ODBCDBE
LOCATE FOR ....
REPLACE ...
CLOSE
oSession:disconnect()

Verfasst: Do, 04. Mai 2006 13:31
von Pope
Hey Jungs,

danke Euch beiden für die schnellen Tips. In der Zwischenzeit habe ich mir selbst in einer 2-Stunden-Crashkurs-Sitzung SQLExpress installiert (hatte ich vorher noch nicht mal installiert), die Beispiele angeguckt, eins davon modifiziert - et voila - funzt einwandfrei.

Vor allem scheint SQLExpress da doch etwas "sauberer" zu arbeiten als die xBase ODBCDBE - denn ein schneller Test mit einer Tabelle, die Indexfelder und andere seltsame Dinge enthält (z.B. erzeugen einer eindeutigen mörder-langen ID im Satz mit NewID() vom SQL-Server) funktioniert nur mit SQLExpress perfekt.

Danke trotzdem - ich teste die anderen Möglichkeiten auch noch durch.

Gruß
Klaus

Verfasst: Do, 04. Mai 2006 13:44
von brandelh
Hallo,

es ist nicht nur sicherer, sondern auch schneller die SQL-Befehle (update, insert ...) zu benutzen. Wer mit select * arbeitet, und später filtert, beschert dem SQL Server, dem Netz und dem Anwender jede Menge unnötiger Arbeit ...

Verfasst: Do, 04. Mai 2006 13:48
von brandelh
Hallo Pope,

du warst mit der Antwort schneller und wolltest zu SQLExpress ja nichts hören :wink: , aber ...

SQL Express macht das Xbase-SQL-Leben wirklich leichter.
Egal ob MySQL, MsSQL Server oder MDB, es lief bei mir auf Anhieb super. Mit ODBCDBE hatte ich so meine liebe Mühe...

Verfasst: Do, 04. Mai 2006 14:51
von Pope
Hey Hubert,

ja - bin auch ganz begeistert von meinen schnellen Erfolgen mit SQLExpress.

Tja - da reiben sich einige Add-On-Entwickler die Hände, daß so einiges was Alaska in den letzten Jahren als Ergänzungen zu xBase++ netterweise dazugepackt hat, eben DOCH oft nicht so ganz perfekt funktioniert hat.

Beispiele gibts ja genug: WAA, FTP, ActiveX, ADS, ODBC usw.

Einige Dinge haben sie ja jetzt etwas "ernsthafter" angepackt - wie ActiveX. Ich hab ja auch nix gegen, für ein Add-On, das Arbeit und Zeit spart, Geld auszugeben -- ich hab bloss Angst vor dem Moment, wo der Dschungel der notwendigen 3rd-Party-Libraries unübersichtlich wird - oder sich zwei Libraries mal nicht "vertragen".

Gruß
Klaus

Verfasst: Do, 04. Mai 2006 15:02
von brandelh
Pope hat geschrieben:ich hab bloss Angst vor dem Moment, wo der Dschungel der notwendigen 3rd-Party-Libraries unübersichtlich wird - oder sich zwei Libraries mal nicht "vertragen".
gerade aus diesem Grunde nehme ich nur, was ich entweder im Quellcode (Xbase++) bekomme oder von Xbase++ Versionen unabhängig ist, also mit C/C++ geschrieben wurde.

Eine Xbase++ DLL für 1.82.294 mit Aussicht auf Update bei 1.90.xxx kann der Hersteller behalten, die würde ich nie nehmen.
Eine Erfahrung von früher.