Laden...

SQL-INSERT beschädigt die ACCESS-Datenbank?!

Erstellt von nikg-fh vor 16 Jahren Letzter Beitrag vor 16 Jahren 2.001 Views
N
nikg-fh Themenstarter:in
27 Beiträge seit 2007
vor 16 Jahren
SQL-INSERT beschädigt die ACCESS-Datenbank?!

MICROSOFT ACCESS

Hallo, ich würde gerne wissen ob es möglich ist, dass ein SQL INSERT-BEFEHL eine
Datenbank beschädigen kann. Ich versuche die Situation so genau wie möglich zu beschreiben.
Eine ACCESS-Datenbank fungiert als eine Schnittstelle zwischen meinem Toll (C#) und einem anderen Programm (COSIMIR - eine 3D-Simulationsprogramm).
Diese Schnittstelle (also die Access-Datenbank) beinhaltet mehrere Tabellen, die NICHT miteinadner verknüpft sind und sonst in keiner Wechselwirkung zu einander stehen.
Bisher habe ich nur mit SELECTS und UPDATES gearbeitet und alles hat perfekt funktioniert.
Nun habe ich (siehe unten) ein DELETE und eine INSERT eingebaut und schon gibt es Probleme.

Tabellen:
ApplicationState - wird von beiden Anwendungen beim Starten permanent abgefragt

Orders - mein C#-Tool fügt dort mit einem INSERT-Befehl den aktuellen Befehl als Nummmer (z.B. 4) ein, welcher von COSIMIR ausgelesen wird. Diese Zahl "4" wird von COSIMIR dazu genutzt, um in der Tabelle CosimirPrograms in der entsprechenden Zeile (also Zeile 4) den Programmnamen und, falls vorhanden, die Parameter (wiederum mit einem SQL-SELECT) rauszulesen.

CosimirPrograms - beinhaltet alle Namen der Programme, die COSIMIR ausführt, bekommt Parameterwerte von meinem C#-Tool und Rückgabewerte von COSIMIR.

VORHER:
Mein C#-Tool schreibt mit UPDATE in die Tabelle Orders den aktuellen Befehl rein.
COSIMIR liest mit SELECT den Befehl in der Tabelle Orders aus und setzt den aktuellen Befehel mit UPADTE wieder auf 0 (0=kein Befehel). Mit diesem Befehl (zB. 4) führt COSMIR weitere Schritte durch (Programmnamen aus der CosimirPrograms-Tabelle lesen, das Programm ausführen und einen Rückgabewert in die CosimirPrograms-Tabelle mit UPDATE schreiben). Mein C#-Tool aus der CosimirPrograms-Tabelle den Rückgabewert rauslesen.

JETZT:
Mein C#-Tool schreibt mit INSERT den aktuellen Befehl in die Tabelle Orders rein.
COSIMIR liest mit SELECT in der Tabelle Orders den aktuellen Befehl und löscht mit DELETE die rausgelesenen Zeile. Analog zur vorherigen Situation liest COSIMIR in der Tabelle CosimirPrograms den Programmnamen führt dieses Programm aus und schreibt erfolgreich den Rückgabewert in die Tabelle CosimirPrograms zurück. Mein C#-Tool versucht mit einem SELECT diesen Rückgabewert rauszulesen und bekommt NICHTS zurück.

Die einzige Änderung besteht darin, dass die UPDATE-Befehle duch DELETE und INSERT ersetzt wurden.

Das Eigenartige ist: Da mein C#-Tool so lange aus der Tabelle zu lesen versucht, bis es einen Rückgabewert bekommt, konnte ich folgendes testen.
Ich mache die Datenbank auf. Lösche darin die Tabelle Orders (nachdem diese mit dem INSERT "beschätigt" wurde) und schon kann mein C#-Tool den Rückgabewert, der die ganze Zeit schon in der Tabelle CosmirPrograms stand, lesen.
Auch wenn ich nach dem INSERT die Tabelle schließe und mein C#-Tool neu starte, kann mein C#-Tool die Werte aus der Tabelle CosimirPrograms nicht lesen, solange die "beschädigte" Orders Tabelle nicht gelöscht wird. Es kommt keine Fehlermeldung, mein Tool kann einfach keinen Wert bekommen, obwohl dieser drin steht. Alle SQL-Abfragen wurden nicht geändert und sind korrekt. Sie funktionieren ja, wenn die Tabelle Orders gelöscht wird.

So jetzt bitte ich Euch um eure Ideen und Meinungen.
Kann man nun eine Datenbank mit einem INSERT-Befehl beschädigen?! Wenn ja wie kommt das genau und wie kann man sowas beheben.
Wenn jemand das Thema spannend findet, kann ich das gesamte Projekt auch hochladen.

M
190 Beiträge seit 2007
vor 16 Jahren

Bei Access ist ja das Problem, dass das keine wirklich tolle Datenbank ist. Ich habe schon öfter Fälle beobachtet, in denen die Integrität nicht mehr gewährleistet war.

Läst du beide Programme gleichzeitig laufen? Vielleicht hast du da ein Problem mit nicht synchronisierten Zugriffen.

N
nikg-fh Themenstarter:in
27 Beiträge seit 2007
vor 16 Jahren

ja beide Programme laufen gleichzeitig.
Das Seltsame ist, dass es zur Zeit ohne Probleme läuft. Neustarts habe ich auch davor schon gemacht, hat aber nichts gebracht.
Und jetzt auf einmal OHNE irgendwelche Änderungen.
Ich stemple es für mich als ein "Bug" ab, es sei denn jemand kann konkret was dazu sagen. Wie gesagt jetzt läuft es ja.

460 Beiträge seit 2004
vor 16 Jahren

Hallo,

ich kann das nur bestätigen. Das kommt leider bei Access vor.
Ich habe das auch schon bei Update Abfragen beobachtet.

Jan

N
nikg-fh Themenstarter:in
27 Beiträge seit 2007
vor 16 Jahren

eine Ursache dafür kennt ihr nicht? Bzw wie man das vermeiden kann?

M
190 Beiträge seit 2007
vor 16 Jahren

Bzw wie man das vermeiden kann?

Nicht Access benutzen 🙂

A
764 Beiträge seit 2007
vor 16 Jahren

Zitat:
Bzw wie man das vermeiden kann?

Nicht Access benutzen smile

4.506 Beiträge seit 2004
vor 16 Jahren

Hallo zusammen,

das ist in der Tat ein allgemein bekanntes Problem. Ich würde hier ganz zwingend raten, dass NIE beide Programme gleichzeitig laufen. Eine Synchronisierung in Access ist nur dann möglich, wenn man selbst dafür sorgen kann.

Wenn ich Dich richtig verstanden habe, dann ist mindestens das eine Programm nicht von Dir und daher nicht zu beeinflussen (umprogrammierbar). Dann hast Du immer das Problem, dass ein gleichzeitiger Zugriff die Integrität Deiner DB zerstört.

Das ist wie beim Multithreading. Ein unsynchronierter Zugriff geht eventuell 999x gut und beim 1000. Mal machts zoom. Genauso ist das mit dem Zugriff auf Deine Access-DB.

Grüße
Norman-Timo

A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”

460 Beiträge seit 2004
vor 16 Jahren

Stimmt, Wenn Du die Möglichkeit hast, nimm irgendwas anderes.

N
nikg-fh Themenstarter:in
27 Beiträge seit 2007
vor 16 Jahren

vielen vielen dank an dieser stelle.
ich werde mich nun wohl oder übel nach einer anderen möglichkeit umschauen.

Ich nehme an bei einer SQL-Datenbank wird mir unter den selben voraussetzungen dieses Problem erspart bleiben oder?

M
190 Beiträge seit 2007
vor 16 Jahren

Du könntest versuchen die MDB exclusiv zu öffnen.
Wenn das allerdings dann sehr oft passiert wird wohl die gesamte Performance leiden.
Ich würd da auch eher zu einer richtigen Datenbank raten.
Oder du nimmst eine Xmldatei oder so und sperrst dann immer nur den kritischen Dateiabschnitt halt da wo du gerade lesen oder schreiben willst.
Wobei ich dazu sagen muss, dass ich nicht weiß ob das mit C# geht das kenn ich halt von C so.

N
nikg-fh Themenstarter:in
27 Beiträge seit 2007
vor 16 Jahren

OK. wie gesagt eine SQL-Datenbank ist vorgemerkt aber ich habe auch die Idee gehabt in Richtung XML bzw Textdatei zu gehen.
Wenn jemand damit schon seine Erfahrungen gemacht hat bitte posten.
Anforderung:
Die XML/TEXT/DATENBANK-Datei stellt eine Schnittstelle zwischen meinem C#-Tool und COSIMIR (ein 3D-Simulationsprogramm dar) diese Schnittstelle wird von beiden Anwendungen PERMANENT abgefragt (aus projekttechnischen Gründen, da mein Tool als eine Steuerungseinheit zur Laufzeit automatisch in die Simulation eingreifen muss). Auf diese Art und Weise erhoffe ich mir ein Kommunikationschannel zwischen beiden Programmen einzurichten.

Es hat ja mit Access auch geklappt, nur hat mir dieses BUG leider das leben unnötig schwer gemacht.

M
190 Beiträge seit 2007
vor 16 Jahren

Also das klappt mir ner Textdatei natürlich auch allerdings musst du die ja auch synchronisieren.
Ich steig immer noch nicht so ganz dahinter was du eigentlich kommunizieren willst zwischen den beiden Programmen, aber es gibt ja ansonsten auch noch die Möglichkeiten der Pipes und MessageQueue.
Das sind ja eigentlich eher die Mittel zur Interprozess Kommunikation.
Das wäre dann allerdings glaube ich ein neues Topic 😉

S
8.746 Beiträge seit 2005
vor 16 Jahren

Mal davon abgesehen, dass eine Datenbank als Schnittstelle in vielerlei Hinsicht suboptimal ist, funktioniert sowas nur mit einem DBMS (Datenbankmanagementsystem), nicht jedoch mit einer DB - die per Definition nur exklusiv mit einer Anwendung (gleichzeitig) zusammenarbeitet.

Zu letzterer gehört eben auch Access und ist somit für deinen Anwendungsfall nicht geeignet (zumindest ohne weitere Sync-Maßnahmen, die gleichzeitigen Zugriff verhindern). Du musst hier schon mindestens zur (kostenlosen) SQL Server Express Edition greifen (ehemals MSDE).

Besser wäre eine direkte Verbindung beider Anwendungen. Performt auch viel besser. Alternativ bietet sich auch MSMQ an. Das hat den Vorteil, dass auch hier Daten persistiert werden, was einem temporären Ausfall des Datenabnehmers auffängt (ohne Datenverlust).

N
nikg-fh Themenstarter:in
27 Beiträge seit 2007
vor 16 Jahren

ooook. also einen derartigen vorschlag habe ich schon erwartet aber in meiner begrenzten zeit als praktikantwerde ich das wahrscheinlich nicht mehr schaffen.

danke für den vorschlag mit der tetxdatei. ich warte noch auf weitere ideen ansonsten gibt es für mich noch eine möglichkeit über die TCP/IP schnittstelle die kommunikation herzustellen.

M
190 Beiträge seit 2007
vor 16 Jahren

Hmm alternativ ist mir gerade noch eingefallen, da hab ich aber auch keine Erfahrungen.

Was ist denn eigentlich wenn man die Mdb als ODBC Datenquelle einrichtet
//Edit:
(ich meine damit in Windows als DSN)

und dann die Verbindung darüber aufbaut.
Spielen dann die Windowstreiber DBMS oder bleibt das trotzdem an der Mdb hängen?
Also läuft die synchronisation dann richtig? Nur so aus Neugier, weiß das jemand?

S
8.746 Beiträge seit 2005
vor 16 Jahren

Nein. ODBC ist nur ein genormter "Zugriffskanal". ODBC selbst besitzt keinerlei Funktionalität, die darüber hinaus geht.

Bei Access wird - wie bei anderen sogenannten Embedded Databases (z.B. SQL Server Compact Eition) - direkt von einer Programmkomponente (bzw. durch einen per DLL referenzierten DB-Treiber) auf das File zugegriffen.

Und bei direktem Filezugriff ist keinerlei Synchronisation möglich. Bei DBMS sitzt ein Stück "Server" dazwischen, über den alle Clients zugreifen müssen. Der Server sorgt für die Synchronisation. Ohne Server kein paralleler Zugriff.

*EDIT*

Ich muss mich korrigieren. Access ist tatsächlich ein - wenn auch ärmliches - DBMS. Die Server-Schicht ist die JET-Engine (MDAC).

Das oben gesagte gilt weiterhin für Embedded DBs, aber Access gehört nicht dazu.

Vielleicht hilft ja das weiter:

http://msdn2.microsoft.com/en-us/library/aa167840.aspx