vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
 vb@rchiv Offline-Reader - exklusiv auf der vb@rchiv CD Vol.4  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2025
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

VB & Datenbanken
Re: Datensatzsperren - Sehr merkwürdig! 
Autor: srcdbgr
Datum: 26.03.07 11:26
Jojo schrieb:
Zitat:

Habe mal schnell 20 GB hin und zurück kopiert ... keine Probleme.
Was ja keine Auswirkungen bei evtl. vorhandenen Sessionproblemen hat und somit keine Aussage liefert.

Zitat:

Ich hatte auch schon die Idee mit dem MDAC. Aber das ist fest im XP drin und die update von der MS Seite lassen sich nicht unter XP installieren ...
Das stimmt so nicht ganz: wenn Du die ADO-Komponenten direkt ins Anwendungsverzeichnis installierst, dann kannst Du Deine "eigene" Version ausliefern... Aber das ist schlechter Stil und nur eine Notlösung wenn gar nichts anderes geht.

Zitat:

Die Frage ist nur warum ein Recordset das als Static und lockOptimistic geöffnet worden ist überhaupt einen Datensatz sperrt.
Mal ne dumme Frage: wenn Du mit adOpenStatic öffnest, wofür brauchst Du dann noch adLockOptimistic?

adOpenStatic = Ruft eine Kopie der abgefragten Daten ab. Daten können nicht geändert werden. Cursor in alle Richtungen beweglich.
adLockOptimistic = Daten werden erst beim Update gesperrt.

Wäre bei adOpenStatic nicht adLockReadOnly (Nur Lesen, Daten können nicht verändert werden [Default]) ausreichend?

Was Du auch machen könntest, wäre mal das ADO Error Objekt auszuwerten, um genauere Fehlerinfo zu erhalten (siehe dazu auch http://www.vbarchiv.net/archiv/tipp_1279.html und http://support.microsoft.com/kb/167957/de).

Da ist mir noch was aufgefallen:
Tritt der Fehler jetzt bei dem Recordset RS oder bei dem Recordset, welches über SDB.Execute erzeugt wird auf? Eigentlich sind das doch voneinander unabhängige Recordsets. Das eine benutzt Du ja zum Lesen und über das andere führst Du die Änderung/Neuanlage durch (und sendest nichts an den Client zurückt). Möglicherweise kommen die beiden sich ins Gehege?

Evtl. hilft Dir zur genaueren Untersuchung des Fehlers tatsächlich das ADO Error Objekt weiter.

Gruß,
Michael

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. (Brian W. Kernighan)

alle Nachrichten anzeigenGesamtübersicht  |  Zum Thema  |  Suchen

 ThemaViews  AutorDatum
Datensatzsperren - Sehr merkwürdig!1.179Jojo24.03.07 09:02
Re: Datensatzsperren - Sehr merkwürdig!741srcdbgr26.03.07 09:29
Re: Datensatzsperren - Sehr merkwürdig!716Jojo26.03.07 10:06
Re: Datensatzsperren - Sehr merkwürdig!878srcdbgr26.03.07 11:26

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
  
   

Copyright ©2000-2025 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel