vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
sevAniGif - als kostenlose Vollversion auf unserer vb@rchiv CD Vol.5  
 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: Jojo
Datum: 26.03.07 10:06

Hey Michael,

erst vielen Dank für Deine detailierte Antwort.

Ich kann die Veränderung im Netzwerk sehr genau bestimmen. Es ist alles gleich geblieben, außer dass ich an den Rechner auf den VB läuft von 2000 auf XP umgestellt habe. Zwischen den XP Rechner und den SQL Server hängen zwei Linksysrouter. Die Verkarbelung ist nach Kat6e. Das Netzwerk läuft auf 100 MB.
Das Netzwerk sollte physikalisch ok sein. Habe mal schnell 20 GB hin und zurück kopiert ... keine Probleme.

Kannst Du ausschließen, dass sich an den Kommunikationswegen zwischen Deinem Client und dem Server etwas geändert hat? Ich meine z.B. neue Router, neue Switche neue Netzwerksegmente, neue Firewall-Regeln, neue ADS (oder anderer Verzeichnisdienst), neue Gruppenrichtlinien, oder geänderte Konfigurationen ...

Nein, das kann ich nicht. Ich bin mir über die Tiefen von XP im detail nicht im klaren. Ich denke, dass es hier liegt.

Das kann irgend etwas kleines sein, das z.B. das Timeout irgendwo im XP kleiner eingestellt ist als es das im 2000 war oder so etwas. Die fRage ist nur wo so etwas eingestellt werden könnte?

An die Windows Firewall habe ich auch schon gedacht, die habe ich aber schon ausgeschaltet.

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 ...

So wie Du das Problem beschreibst liegt wahrscheinlich keine Datensatzsperre vor.

Bei diesem Code hatte ich immer das Problem:

do until eof(1)
     Line input #1,TS
     Feld = Split(TS,";")
 
     '--- überprüfen, ob es den Artikel schon gibt ---
     SQL = "select * from Artikel where Artikel='" & Feld(1) & "'"
     RS.Open SQL, SDB, adOpenStatic, adLockOptimistic
     If RS.EOF = False Then
         ' --- bestehenden Artikel ändern ---
         Query = "Update Artikel Set OEM='" & Feld(11) & " where Artikel='" & _
           Feld(1) & "'"
     Else
         '---- neu anlegen ----
         Query = "Insert into artikel ..."
     End If
     SDB.Execute Query, , adExecuteNoRecords
     RS.Close
 
loop
Ich habe das mal so umgestellt dass ich das RS.close vor den execute Query mache und damit funktioniert es. Ich denke also schon, dass es irdend etwas mit einer Sperre zu tun hat.

Die Frage ist nur warum ein Recordset das als Static und lockOptimistic geöffnet worden ist überhaupt einen Datensatz sperrt.

So wie ich das adOpenStatic verstanden habe, holt es sich die gesamten Sätze des Recordset und aktualiesierungen während der Laufzeit werden nicht mehr berücksichtigt. Damit auch nicht der gesendete update oder Insert Befehl.

...

Joachim

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!717Jojo26.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