Updaten einer MS-SQL-Server-Tabelle per ODBC ????
Moderator: Moderatoren
- Pope
- Cut&Paste-Entwickler
- Beiträge: 40
- Registriert: Mi, 08. Feb 2006 22:00
- Wohnort: bei Karlsruhe (D)
- Kontaktdaten:
Updaten einer MS-SQL-Server-Tabelle per ODBC ????
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
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
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
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.
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.
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 ..."
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.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
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:
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()
Herzlich,
Tom
Tom
- Pope
- Cut&Paste-Entwickler
- Beiträge: 40
- Registriert: Mi, 08. Feb 2006 22:00
- Wohnort: bei Karlsruhe (D)
- Kontaktdaten:
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
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
- Pope
- Cut&Paste-Entwickler
- Beiträge: 40
- Registriert: Mi, 08. Feb 2006 22:00
- Wohnort: bei Karlsruhe (D)
- Kontaktdaten:
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
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
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
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.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".
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.
Gruß
Hubert
Hubert