Inoffizielles deutsches Xbase-Forum

Eine Verständnisfrage zu SQl Servern:

wenn ein SQL Server einen Satz erhält, in dem er meintewegen ein Update machen soll auf einen Satz, den es noch nicht gibt, dann macht er das ja nicht. Was gibt er dann zurück und kann man sowas dann in ein Protokoll schreiben, das man später auslesen kann? Das Einlesen solcher Sätze wird ja meistens im Hintergrund gemacht.

Manfred hat geschrieben:Eine Verständnisfrage zu SQl Servern:

wenn ein SQL Server einen Satz erhält, in dem er meintewegen ein Update machen soll auf einen Satz, den es noch nicht gibt, dann macht er das ja nicht. Was gibt er dann zurück und kann man sowas dann in ein Protokoll schreiben, das man später auslesen kann? Das Einlesen solcher Sätze wird ja meistens im Hintergrund gemacht.

Es gibt bei den meisten die Möglichkeit, die 'RowsUpdated' auszulesen. Falls 0, fand er keinen Datensatz zum Update.

Hallo, Manfred -


je nach Implementierung bekommt man einen Fehlercode zurück:
Bei MySQL gibt es noch dem umgekehrte Weg, wenn die Datei einen PRIMARY KEY hat, dann macht man den INSERT mit der ON DUPLICATE KEY Option und hängt dort entsprechende UPDATE Statements an. Gibt es bereits einen Satz mit dem gleichen Key, wird der INSERT nicht ausgeführt, aber die UPDATE Anweisungen.

Bevor wir jetzt ins Nirwana verschwinden eine kurze Erklärung:

Ich erzeuge eine CSV Datei in der Inserts und Updates stehen. Das klappt auch eigentlich ohne Probleme. Je Satz stehen nur die DAten, die dann vom SQL Server eingelesen werden. Er bekommt nur kurz am Anfang einen Hinweis für Insert oder Update oder Delete. Jetzt kann es aber passieren, dass ein Satz nicht eingefügt wird oder wurde und somit ein Update nicht mehr klappt. Der Kunde bekommt immer nur mit, das der Satz dann in der Datenbank nicht geändert wurde. Also am Frontend, wenn er sich die Daten fertig anschauen möchte. Ich suche mir dann einen heißen, woran es liegen könnte. Bekomme aber nicht mit, wann und warum der Satz nicht insert wurde, bzw. warum kein Update erfolgte. Wichtig wäre für mich zu erfahren das es kein Update gab und warum. Es kann ja sein, das die DAtei mit den Inserts überhaupt gar nicht geliefert wurde an den SQl Server und somit wurde auch nichts eingefügt. Aber wenn der SQL Server mir jetzt in einem Protokoll mitteilen würde: "Achtung kein Update, weil nicht vorhanden o.ä., das ich dann auslesen kann um den Satz nachzuliefern. Damit wäre mir sehr geholfen. Das würde die Sache dann auf den ersten Blick erstmal automatisieren. Deshalb meine Frage, ob ein SQL Server sowas protokollieren kann, ich mir dann die Datei runterlade und nachschaue ob und was drin steht.

Du schreibst CSV Datei, kann der die direkt verarbeiten oder meinst du eine SQL Anweisungsdatei die dort an der Console verarbeitet wird ?

Wieviele Datensätze sind es denn ?

Bei NUR einigen hundert, könntest DU ein Programmschreiben, dass die Sätze einliest und auf Fehler reagiert.

Hallo Hubert,

so wie ich Manfred verstehe ist genau DAS sein Problem. Im Moment kann er einfach nur die Update-Anweisungen an die SQL schicken. Aber wie bekommt er die Rückmeldung, das ein UPDATE mangels eines entsprechenden, vorhandenen Satzes gescheitert ist?

Jan

Moin,
von welchem Dialekt reden wir denn? Manche können auch "INSERT OR REPLACE..." verstehen. Ist der Satz da, wird er geupdatet, ansonsten angelegt.

Viele Grüße,
Martin

Genau das war meine Frage gewesen, WER macht WAS und WIE ... ein ADMIN am Server über die Konsole ???

DER müsste Serverlogs einstellen und auslesen/übersenden können.
Mich machte nur die CSV Datei stutzig ...

Hinzu kommt, dass man wohl den Server kennen muss, weil jeder andere Möglichkeiten hat.

ich erzeuge nur eine CSV Datei, in der Daten stehen. Die wird dann wohl vom SQL Server importiert oder so. Wie schon erwähnt steht am Anfang jedes Satzes ein Kennzeichen anhand dessen erkannt wird ob Insert oder Update. Keine SQL BEfehle von mir, nur reine Datenfolgen.

CSV-Import gehört meines Wissens nicht zum Standard-SQL-Sprachumfang. Ich nehme an, dass es eine gesondert implementierte Importschnittstelle gibt, und zwar im Frontend - und nicht im Server selbst. Ein SQL-Server kann SQL-Dump einlesen, beziehungsweise kann man derlei in die Konsole pasten und dort ausführen lassen. CSV steht für "Comma separated values", also durch Kommata getrennte Werte. Mit denen muss irgendwas passieren, damit sie in eine SQL-Tabelle wandern; was und wohin, das muss man wissen. Es gehört schlussendlich ein Statement dazu, aber welches und wo das ausgeführt wird, das müsste man erst einmal erforschen.
Bei MySQL gibt es z.B. das "mysqlimport"-Tool, das verwendet werden kann, oder das "LOAD DATA INFILE"-Kommando. Wenn etwas davon verwendet wird, muss man eben schauen, womit es antwortet. Das kann man aber nur, wenn man die Kommandos selbst auslöst.

Wenn man weiß, welche Tabelle in welcher Datenbank angesprochen werden soll, kann man das in der eigenen Anwendung auch selbst machen - in 2.0 geht es wahrscheinlich direkt, vorher mit SQLexpress via ODBC, was aber auch kein großer Schuh ist. Dann kann man sich den Umweg über eine CSV-Datei auch ersparen. Vorausgesetzt, man kommt aus der Anwendung heraus an den Server.

ich sehe schon, es läuft wieder aus dem Ruder. Ich erstelle nur eine CSV Datei mit Daten. Die wird dann eingelesen für oder mit dem SQL Server. Wie weiß ich nicht, ist auch nicht meine Baustelle. Ich wollte auch nur wissen, was ein SQl Server zurückgibt, wenn man auf der Console ein SQL Statement absetzen würde, was nicht vernünftig abgearbeitet werden kann. Da müßte doch eigentlich einen Meldung kommen. Wenn sowas nun zeitgesteuert über einen Job geschieht, dann müßte da ja auch was zurückgegeben werden. Und das war nur meine Frage, ob das der Fall ist und ob man sowas entweder komplett oder fallweise je nach Vorgang wegschreiben kann um es dann mit einem anderem Programm auszulesen. Mehr nicht. Ich kann nicht an den Server und will es auch nicht. Das Teil wird von ganz anderer Stelle im Internet gepflegt. Ich liefere nur Daten. Nur bevor ich jetzt wilde Vorschläge an den Dienstleister für den SQL Server richte, wollte ich erstmal wissen, ob es überhaupt sowas gibt. Sicherlich, aber evtl. mit welchem Aufwand.

Hallo, Manfred.

Wenn man ein Statement in der Admin-Konsole o.ä. ausführt, erzählt einem der Server, was er gemacht hat. Also ob es einen Fehler gab und/oder wie viele Zeilen (der Tabelle) aktualisiert wurden. Etwas ähnliches bekommt man in aller Regel zurück, wenn man das aus der eigenen Anwendung heraus tut. Also, ja, man kann meistens durchaus sehen, ob und in wie vielen Fällen das erfolgreich war. Im Detail ist das bei jedem Server (MySQL, MS-SQL, PostGre, ADS/DD, SQlite) anders.

Wenn das Statement eingebettet - in der Anwendung, z.B. im Importtool - ausgeführt wird, hängt es davon ab, ob das Tool auf die Serverantwort reagiert. In PHP beispielsweise wird ein Fehler-/Antwortstatus generiert, wenn man ein Statement via "mysql_query" ausgeführt hat, aber das Ding gibt nur TRUE oder FALSE zurück. Was genau passiert ist, kann man dann nur durch Vergleich über mysqladmin herausbekommen. Es gibt aber auch erweiterte/neuere Fassungen dieser Funktionen, die möglicherweise mehr tun.

Anders gesagt: Es hängt von der konkreten Situation ab.

Hi Tom,

Danke, das war jetzt das was ich nicht hören wollte, aber ich hatte es schon vermutet. Schade. Ich war im Glauben, man könnte das schön elegant machen wie unter xbase++. Also bedeutet das, es gibt ein .T. zurück wenn es klappte und ein .F. wenn es nicht klappte. Naja, würde aber auch schon weiterhelfen. Allerdings muß dann auch noch ein Hinweis auf den Datensatz gegeben werden, damit man weiß welcher Satz nicht klappte. Na dann muß ich mal ins Gespräch gehen und schauen was wir für Möglichkeiten haben.

wenn wir von PostgreSQL sprechen : über die "PSQL Console" mit dem "SQL Copy" Befehl einlesen.
default ist das Logbuch eingeschaltet wo man sehen kann ob alles OK ist.

bei MySQL : über die "Workbench" mit dem "LOAD DATA INFILE" Befehl.
dito im Logbuch nachsehen ob alles OK war.

Hallo, Manfred -


wenn Du wirklich ein Protokoll brauchst (und danach hört es sich an), würde ich die CSV-Datei selbst einlesen und über eine entsprechende Schnittstelle (z.B. SQLExpress, wenn für den SQL-Server ein ODBC-Treiber vorhanden ist) die Sätze einzeln "verfüttern". Damit kommst Du dann an die Rückmeldung des Servers und kannst ein ordentliches Protokoll erstellen.

Hi Georg,

nochmal: Ich habe keinen Zugriff auf den Server.

Und? Brauchst du doch auch nicht! Einfach vom Client aus per ODBC. Auf dem Server musst du nichts machen.

Manfred hat geschrieben:ich sehe schon, es läuft wieder aus dem Ruder. Ich erstelle nur eine CSV Datei mit Daten. Die wird dann eingelesen für oder mit dem SQL Server. Wie weiß ich nicht, ist auch nicht meine Baustelle.

Genau das ist dein Problem, ohne zu wissen wie das genau abgeht, kann keiner sagen welche Protokolle möglich sind

@Martin,

was habe ich davon? Ich weiß doch gar nicht was ich wie wo und warum angeben muß. Oder hast Du jetzt nicht gemeint ich solle darüber den Server selbst beschicken?

Manfred,
wenn du vom Client die Änderungen machst, kannst du immer entsprechend reagieren!
Wenn du die Attribute am SQL-Server nicht kennst (Schema, Tabellen, Felder), dann musst du dich entsprechend schlau machen (lassen).

Viele Grüße,
Martin

Hallo, Manfred.

Wenn ich Dich richtig verstehe, generierst Du eine Exportdatei, die Datensätze einer SQL-Datenbank aktualisieren soll. Das geschieht via CSV; für den Import gibt es vermutlich eine propreitäre Lösung. Du weißt allerdings nicht genau, in welcher Datenbank und dort in welcher Tabelle die Daten landen. Manchmal ist es allerdings so, dass die Aktualisierung fehlschlägt, weil die Datensätze, die aktualisiert werden sollen, noch nicht oder nicht mehr vorhanden sind. Richtig?

Du hast ein Problem mit Synchronizität und Datenhoheit. Das hat man eben, wenn zwei unterschiedliche Anwendungen Datenbestände manipulieren. Ich würde sagen, dass die Schnittstelle bzw. der Prozess falsch definiert ist. Es hat keinen Sinn, aus einer Anwendung heraus die Aktualisierung von Datensätze auszulösen, von denen man in dieser Anwendung nicht sicher sein kann, dass sie in der Zielanwendung auch existieren, weil man keine Kontrolle über diese andere Anwendung hat. Es liegt also ein Designfehler im Prozess vor. Den sollte man beseitigen, sonst hat der Ablauf möglicherweise überhaupt keinen Sinn. Wenn der Benutzer nicht sicher sein kann, dass Daten ankommen, und es keine Kontrollmöglichkeiten gibt, ist der Prozess nicht verlässlich und nahezu obsolet.

Wenn Dir Informationen darüber zur Verfügung gestellt werden, wie die Datenbank aussieht und um welche Tabelleninhalte es geht, kannst Du aus einer Xbase++-Anwendung direkt darauf zugreifen, im einfachsten Fall über die ODBCDBE. Dafür brauchst Du nur den richtigen Connect zur Datenbank und Informationen über die verwendeten Tabellen. Eleganter ginge es mit SQLexpress oder Xbase++ 2.0. Wenn Dir das nicht gestattet wird oder diese Art von Kontrolle keinen Sinn hat, wirst Du damit leben müssen. Alternativ zur Absicherung der Daten vor der Übergabe kannst Du natürlich auch in Deiner Anwendung prüfen, ob die Daten angekommen sind. Das wäre allerdings schwierig, weil Du vermutlich nicht weißt, wann der Importprozess ausgelöst wird. Anders gesagt: Es sieht so aus, als würdest Du Dich mit Deiner Systematik an der schwächsten Stelle befinden.

Hi Tom,

Du hast vollkommen recht. Es ist so. Leider. Aber es wurde jetzt eine glorreiche Lösung gefunden. Der Verwalter des Shops wird gebeten vor der Übernahme der Daten eine Kopie der Daten anzulegen, die er von mir erhalten hat. In der Kopie schaut dann ein Mitarbeiter nach, wenn es Probleme gibt, ob er die erkennen kann. Das wird jetzt versucht abzustimmen. Ist doch ne geniale Lösung, oder nicht? =D>

Das nennt man EDV zu Fuß

CSV ... hast du Memofelder die mehrere Zeilen enthalten können ?

Eine Zeilenschaltung ist im CSV erlaubt, wenn sie zwischen " " eingeschlossen ist.
Keine meiner Einleseroutinen hat das berücksichtigt, da für mich immer CRLF vorging ...

Ich verstehe die Frage in dem Zusammenhang jetzt nicht Hubert