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

alles zum Microsoft SQL Server

Moderator: Moderatoren

Antworten
Benutzeravatar
Pope
Cut&Paste-Entwickler
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 ????

Beitrag 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
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag 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.
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Beitrag 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()
Herzlich,
Tom
Benutzeravatar
Pope
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 40
Registriert: Mi, 08. Feb 2006 22:00
Wohnort: bei Karlsruhe (D)
Kontaktdaten:

Beitrag 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
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag 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 ...
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag 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...
Gruß
Hubert
Benutzeravatar
Pope
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 40
Registriert: Mi, 08. Feb 2006 22:00
Wohnort: bei Karlsruhe (D)
Kontaktdaten:

Beitrag 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
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag 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.
Gruß
Hubert
Antworten