Änderung an Dataset zu komplex

[informatikerin86]

Guten Morgen,

ich kämpfe seit letzter Woche mit einem Problem an meiner VB.net Anwendung mit Datenbankanbindung.

Ich habe eine Form auf der ich viele Textfelder haben die ausgefüllt werden können. Dabei unterscheide ich zwischen Neuanlage eines Datensatzes und Änderung an einem einzelnen Datensatz. Die Neuanlage wird gespeichert, nur bei der Änderung bringt es die Fehlermeldung: "Abfrage zu komplex".

Falls jemand schon Nachrichten von mir gelesen hat weiß er das ich jede Form 7mal erstelle für veschiedene Abteilungen. Die anderen haben weniger Felder, hier funktionieren die Änderungen.

Meine Frage ist nun was ich machen könnte um die Änderungen speichern zu können.

Ich arbeite übrigens mit dem Designer da meine Abfragen wirklich giantisch groß und lange wären.

Hat vielleicht jemand eine Idee?

Viele Grüße

Informatikern

[0815FIA]

Wenn du eine Access Datenbank benutzt, kann es daran liegen:

Abfrage zu komplex - ADO-Access-VB6 - gulli:board

[informatikerin86]

Danke für den Link.

Das scheint mir dasselbe Problem zu sein.

Allerdings kann ich nicht auf DAO umsteigen, da ich das nur vom hören kenne und da meine restliche Anwendung auf ADO basiert und funktioniert.

Ich könnte versuchen Spaltennamen in der Tabelle zu kürzen, das werde ich direkt mal versuchen. Das Problem das eine andere Anwendung ebenso auf die DB zugreift lasse ich dabei mal außen vor um zu schauen ob es mein Problem zumindest lösen kann.

Kleinere Tabellen sind übrigens nicht möglich (ist ja nicht meine persönliche DB)

[informatikerin86]

so, nun habe ich die spalten auf das extremste gekürzt... und es funktioniert leider immer noch nicht!

weißt jemand was ich jetzt noch tun kann?

ich habe überlegt den Datensatz (der einzeln aufgerufen wird) zu löschen, die Textfelder vorher auszulesen und dann sozusagen den Datensatz neu zu erstellen. blöderweise gibt er mir dieselbe Fehlermeldung aus...

[Gateway_man]

Hm selbigen Fehler hatte ich auch schon.

Hab das Problem nicht gelöst, sondern eher umgangen.

Ich bin auf eine Lokale SQL Datenbank umgestiegen.

Funktioniert gut. Man muss nur beachten, das das File eine maximale Größe von 4GB haben kann und "nur" 255 gleichzeitige Zugriffe erlaubt sind.

Lg

Gateway

[informatikerin86]

@Gateway_man: deine antwort deprimiert mich etwas... von meinem konzern ist sql komplett verboten, es muss egal wie mit access gemacht werden und zwar ganz genau mit access 2000... Also gibt es für mich diesen Workaround leider nicht

[informatikerin86]

Guten Morgen,

nach einem deprimierenden Montag habe ich eine Lösung für mein Problem gefunden. Ich muss zugeben, sie ist nicht gerade elegenat aber es funktioniert!

Beim Erstellen der DataTable im Designer des DataSets gibt es Erweiterte Einstellungen, wenn ich den Haken bei "Vollständige Parallelität verwenden" weglasse dann klappt das Speichern von Änderungen!

Wenn nun zwei Benutzer gleichzeitig Änderungen vornehmen und abspeichern gibt es Speicherkonflikte. Wir haben allerdings beschlossen, das diese Möglichkeit fast ausgeschlossen ist. Mit der Anwendung arbeiten etwa 100 Leute, davon haben 10 die Berechtigung Änderungen zu machen auf 7 verschiedenen Tabellen. Die DB wird sehr selten überhaupt verändert nachdem die Anwendung eingeführt wurde. Ich mache mir da also keine Gedanken.

Falls das also jemand später liest und hofft sein Problem ebenso lösen zu können wünsche ich ihm viel Glück!!!

Viele Grüße und vielen Dank für alle Antworten!

Informatikerin

[streffin]

Mhm du hast jetzt nich wirklich gesagt wie du das Problem umgangen hast.

Gelöst erscheint mir der falsche Begriff, weil ihr ja mehr oder weniger sagt, basst scho passiert scho nix.

Das ganze is der VS Sqlconnector oder ? Also dieses Toolbar dings da, mach mir DB Verbindung ohne das ich quellcode schreiben muss Dings da, oder seh ich da was falsch grad?

Wie auch immer, wenn 100 Leute auf die Daten zugreifen, warum löst ihr das nicht über ne Funktion im Frontend "Schreibrechte anfordern" und durch die Funktion den einen Datensatz der bearbeitet werden soll, flaggt, einfach ne neue Boolean Spalte "gesperrt" oder falls machbar ne int / varchar spalte "gesperrt_fuer". Wie auch immer das bei euch läuft, ob das per Domäne und thrusted authentification oder per standart userid und pw läuft, etc

Ein User A fordert schreibrechte an, Datensatz wird geflaggt, kein anderer kann in der Zeit den Datensatz editieren. User A speichert seine Änderungen, Datensatz wird wieder freigegeben.

Solange User A den Schreibzugriff hat, können alle anderen User den Datensatz nur lesen, aber nicht verändern.

Das wär ne saubere Sache dann.

Jetzt allein von der Logik her, wenn das wirklich dieses klick klick zieh db dings von VS sein sollte, ähm ja, DB sachen mach ich da dann doch lieber von Hand muss ich sagen, da weis ma wenigstens was passiert (in der Regel)

Das wär jetzt mal grob was ich zu der Thematik sagen würde

//edit :

Da is jetzt recht schnuppe ob das Access 2000 oder ne richtige DB ist (nein ich mag Access nicht). Ne Spalte dazu, die Flagt ob der Datensatz editierbar ist oder nicht, stellt sicher, dass sich user nicht gegenseitig die Daten überschreiben ohne das se refresht sind. Ob das jetzt Access, Mysql, MsSql, oder Oracle ist, am Prinzip ändert das alles nix.

Genauso ändert das nix daran, das ich dir sehr ans Herz leg, selber die DB connection aufzubauen, da bist du sehr viel freier was Fehlerbehandlung angeht. Und Access is au nur nen anderer Treiber / connection string, alles Jacke wie Hose was die verwendete DB angeht. ok, andere syntax fürs sql statement zum Teil, aber ja, Jacke wie Hose

Gruss

Sven

Bearbeitet 20. Oktober 2009 von streffin

[informatikerin86]

@streffin:

Ich habe anfangs auch alles von Hand gemacht da mich der Designer manchmal etwas irritiert und ich gerne auch mal den kompletten Code sehe und am allerliebsten auch verstehe! Allerdings ist das Erstellen von Abfragen per Hand gar nicht so witzig wenn man zig Tabellen mit bestimmten Kriterien reinladen will, wenn ich mir die generierten Abfragen anschaue dann passen die kopiert schon mal auf eine komplette Word-Seite drauf.

Also lasse ich das ganze doch vom designer machen.

Zu dem "basst scho passiert scho nix:

Es sind wie beschrieben 10 Mitarbeiter die Änderungen vornehmen dürfen. Allerdings ist die DB nicht wirklich gedacht um Änderungen zu machen, das passiert sehr sehr selten. Was für ein Zufall müsste das sein wenn 2 Leute gleichzeitig an ein und demselben Datensatz Änderungen machen?

Es ist auch eine Zeitfrage wenn ich Access mit den ganzen Front-End und Back-End Zeug aufbauen müsste, wobei ich sagen muss das ich mich damit eigentlich gar nicht auskenne. Warum also mehr Arbeit machen wenn alle mehr als zufrieden sind mit meiner Lösung?

Du darfst mich von mir aus als schlechte Programmiererin bezeichnen, das nehme ich dann eben an...

Jedes Projekt ist anders und jeder Programmierer arbeitet anders!

[paslanmazbul]

Hallo, mit Access-Datenbank.

Mit MySQL oder SQL Server.

Projekt zeigt, dass der Fehler

i

Sie löst den Fehler.

[grueni]

Could you try in English Paslan? Your German does not make much sense.

[0815FIA]

Ich glaube er wollte sagen, dass Sie auf eine MySQL oder MSSQL Datenbank umsteigen soll, da es das 64k Problem dort nicht gibt. Geht ja aber sowieso nicht, da die DB vorgegeben ist.