Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ODBC-Problem, Access 2002, SQL-Server 2005
89 views
Skip to first unread message
alpw...@gmail.com
May 17, 2012, 4:57:31 PM5/17/12
to
Liebe Experten,
von einem Access Frontend verbinde ich über ODBC zu einem SQL Server 2005
Connect String:
"ODBC;DRIVER={SQL Server};SERVER=<<server name>>;DATABASE=<<database name>>;Trusted_Connection=Yes;"
Die Tabellendaten zeige ich in einem Datenblatt-Formular, welches wiederum in einem anderem Formular eingebettet ist.
Wenn ich einen Datensatz bearbeite funktioniert alles soweit, bearbeite ich aber einen zweiten Satz (manchmal passiert das auch erst beim dritten oder vierten), dann kommt folgende Meldung:
"Die Daten wurden geändert.
Ein anderer Benutzer hat diesen Datensatz bearbeitet und die von ihm vorgenommenen Änderungen gespeichert, bevor Sie versucht haben, Ihre Änderungen zu speichern.
Bearbeiten Sie den Datensatz erneut."
Jedenfalls bin ich zu diesem Zeitpunkt der einzige der sich zur Datenbank verbindet.
Vielen Dank im voraus für jede Anregung.
W Baumann
von einem Access Frontend verbinde ich über ODBC zu einem SQL Server 2005
Connect String:
"ODBC;DRIVER={SQL Server};SERVER=<<server name>>;DATABASE=<<database name>>;Trusted_Connection=Yes;"
Die Tabellendaten zeige ich in einem Datenblatt-Formular, welches wiederum in einem anderem Formular eingebettet ist.
Wenn ich einen Datensatz bearbeite funktioniert alles soweit, bearbeite ich aber einen zweiten Satz (manchmal passiert das auch erst beim dritten oder vierten), dann kommt folgende Meldung:
"Die Daten wurden geändert.
Ein anderer Benutzer hat diesen Datensatz bearbeitet und die von ihm vorgenommenen Änderungen gespeichert, bevor Sie versucht haben, Ihre Änderungen zu speichern.
Bearbeiten Sie den Datensatz erneut."
Jedenfalls bin ich zu diesem Zeitpunkt der einzige der sich zur Datenbank verbindet.
Vielen Dank im voraus für jede Anregung.
W Baumann
Peter Doering
May 17, 2012, 5:37:03 PM5/17/12
to
Hallo,
alpw...@gmail.com wrote:
> von einem Access Frontend verbinde ich über ODBC zu einem SQL Server 2005
> [...]
vornimmst? Dann waerst du selbst derjenige, der die Aenderungen vorgenommen
hat.
Achte auch darauf, dass jede Tabelle am SQL Server ein Feld vom Typ
Timestamp enthaelt.
Gruss - Peter
--
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com
alpw...@gmail.com wrote:
> von einem Access Frontend verbinde ich über ODBC zu einem SQL Server 2005
> Die Tabellendaten zeige ich in einem Datenblatt-Formular, welches
> wiederum in einem anderem Formular eingebettet ist. Wenn ich einen
> Datensatz bearbeite funktioniert alles soweit, bearbeite ich aber einen
> zweiten Satz (manchmal passiert das auch erst beim dritten oder
> vierten), dann kommt folgende Meldung:
>
> "Die Daten wurden geändert. Ein anderer Benutzer hat diesen Datensatz
> bearbeitet und die von ihm vorgenommenen Änderungen gespeichert, bevor
> Sie versucht haben, Ihre Änderungen zu speichern. Bearbeiten Sie den
> Datensatz erneut."
Kann es sein, dass du per Code/SQL Aktualisierungen am aktuellen Datensatz
> wiederum in einem anderem Formular eingebettet ist. Wenn ich einen
> Datensatz bearbeite funktioniert alles soweit, bearbeite ich aber einen
> zweiten Satz (manchmal passiert das auch erst beim dritten oder
> vierten), dann kommt folgende Meldung:
>
> "Die Daten wurden geändert. Ein anderer Benutzer hat diesen Datensatz
> bearbeitet und die von ihm vorgenommenen Änderungen gespeichert, bevor
> Sie versucht haben, Ihre Änderungen zu speichern. Bearbeiten Sie den
> Datensatz erneut."
vornimmst? Dann waerst du selbst derjenige, der die Aenderungen vorgenommen
hat.
Achte auch darauf, dass jede Tabelle am SQL Server ein Feld vom Typ
Timestamp enthaelt.
Gruss - Peter
--
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com
alpw...@gmail.com
May 17, 2012, 7:22:19 PM5/17/12
to
> Kann es sein, dass du per Code/SQL Aktualisierungen am aktuellen Datensatz
> vornimmst? Dann waerst du selbst derjenige, der die Aenderungen vorgenommen
> hat.
>
> Achte auch darauf, dass jede Tabelle am SQL Server ein Feld vom Typ
> Timestamp enthaelt.
>
> Gruss - Peter
Lieber Peter,
> vornimmst? Dann waerst du selbst derjenige, der die Aenderungen vorgenommen
> hat.
>
> Achte auch darauf, dass jede Tabelle am SQL Server ein Feld vom Typ
> Timestamp enthaelt.
>
> Gruss - Peter
Danke für die Antwort.
Nein, per Code gibt es in diesem Formular keinerlei Datensatzzugriff.
(Das Problem tritt auch auf, wenn ich aus dem Formular den gesamten Code entferne)
Ja, in jeder Tabelle gibt es ein Timestamp-Feld.
LG, W
Peter Doering
May 18, 2012, 3:17:32 AM5/18/12
to
Hallo,
alpw...@gmail.com wrote:
>> Kann es sein, dass du per Code/SQL Aktualisierungen am aktuellen Datensatz
>> vornimmst? Dann waerst du selbst derjenige, der die Aenderungen vorgenommen
>> hat.
>>
>> Achte auch darauf, dass jede Tabelle am SQL Server ein Feld vom Typ
>> Timestamp enthaelt.
>
ODBC/SQL Server sind bei ihren Meldungen relativ spassfrei. Wenn diese
Meldung kommt, dann ist das i.d.R. auch der Fall. Wenn nicht per Code, hast
du evtl. ein weiteres Formular geoeffnet, das die gleichen Daten als
Herkunft hat?
Wenn du das alles ausschliessen kannst, wuerde ich mal auf einem anderen
Rechner, anderer Access-Version probieren, ob das Verhalten dort
reproduzierbar ist.
alpw...@gmail.com wrote:
>> Kann es sein, dass du per Code/SQL Aktualisierungen am aktuellen Datensatz
>> vornimmst? Dann waerst du selbst derjenige, der die Aenderungen vorgenommen
>> hat.
>>
>> Achte auch darauf, dass jede Tabelle am SQL Server ein Feld vom Typ
>> Timestamp enthaelt.
>
> Nein, per Code gibt es in diesem Formular keinerlei Datensatzzugriff.
> (Das Problem tritt auch auf, wenn ich aus dem Formular den gesamten Code
> entferne)
Zeig mal den Code.
> (Das Problem tritt auch auf, wenn ich aus dem Formular den gesamten Code
> entferne)
ODBC/SQL Server sind bei ihren Meldungen relativ spassfrei. Wenn diese
Meldung kommt, dann ist das i.d.R. auch der Fall. Wenn nicht per Code, hast
du evtl. ein weiteres Formular geoeffnet, das die gleichen Daten als
Herkunft hat?
Wenn du das alles ausschliessen kannst, wuerde ich mal auf einem anderen
Rechner, anderer Access-Version probieren, ob das Verhalten dort
reproduzierbar ist.
alpw...@gmail.com
May 18, 2012, 3:46:09 PM5/18/12
to
Lieber Peter,
zunächst mal Danke für dein Engagement.
Ich weiss es wirklich zu schätzen.
> Zeig mal den Code.
Ich habe dir unter:
http://www.klbg.com/odbc/0a_Test.mdb
die abgespeckte DB bereitgestellt, die gerade noch den Fehler reproduziert.
Unter:
http://www.klbg.com/odbc/20120518_odbc2.htm
kannst du ein kurzes Video sehen was passiert.
In diesem speziellen Fall ist es anders als beschrieben kein Datenblattformular welches eingebettet ist, sondern ein Endlosformular. Im Prinzip ergibt sich aber genau der gleiche Fehler.
Wie du aus beiden erkennen kannst, läuft eigentlich gar kein Code.
Das ODBC-Verknüpfung baue ich einmalig dynamisch mit "call connect" auf, siehe modConnect. (Muss nicht bei jedem Programmstart gemacht werden.)
> du evtl. ein weiteres Formular geoeffnet, das die gleichen Daten als
> Herkunft hat?
Es gibt nur 1 Formular. (In der Beispielanwendung, die den Fehler produziert)
> Wenn du das alles ausschliessen kannst, wuerde ich mal auf einem anderen
> Rechner, anderer Access-Version probieren, ob das Verhalten dort
> reproduzierbar ist.
Nein, vom Rechner hängt es nicht ab, und ich denke auch nicht von der Accessversion, ich werde ausserdem weiterhin auch Access 2002 unterstützen müssen (neben Access 2010).
Vielen Dank, LG, W
zunächst mal Danke für dein Engagement.
Ich weiss es wirklich zu schätzen.
> Zeig mal den Code.
Ich habe dir unter:
http://www.klbg.com/odbc/0a_Test.mdb
die abgespeckte DB bereitgestellt, die gerade noch den Fehler reproduziert.
Unter:
http://www.klbg.com/odbc/20120518_odbc2.htm
kannst du ein kurzes Video sehen was passiert.
In diesem speziellen Fall ist es anders als beschrieben kein Datenblattformular welches eingebettet ist, sondern ein Endlosformular. Im Prinzip ergibt sich aber genau der gleiche Fehler.
Wie du aus beiden erkennen kannst, läuft eigentlich gar kein Code.
Das ODBC-Verknüpfung baue ich einmalig dynamisch mit "call connect" auf, siehe modConnect. (Muss nicht bei jedem Programmstart gemacht werden.)
> du evtl. ein weiteres Formular geoeffnet, das die gleichen Daten als
> Herkunft hat?
> Wenn du das alles ausschliessen kannst, wuerde ich mal auf einem anderen
> Rechner, anderer Access-Version probieren, ob das Verhalten dort
> reproduzierbar ist.
Vielen Dank, LG, W
alpw...@gmail.com
May 18, 2012, 4:49:48 PM5/18/12
to
Jemand hat mich auf folgenden kb-Artikel aufmerksam gemacht:
http://support.microsoft.com/kb/302492
Dort wird genau das Problem beschrieben.
Nur die beschriebene Lösung scheint nicht ganz zu funktionieren,
aber immerhin.
Peter Doering
May 19, 2012, 11:04:51 AM5/19/12
to
Hallo,
alpw...@gmail.com wrote:
>
>> Zeig mal den Code.
> Ich habe dir unter:
> http://www.klbg.com/odbc/0a_Test.mdb
> die abgespeckte DB bereitgestellt, die gerade noch den Fehler reproduziert.
> Unter:
> http://www.klbg.com/odbc/20120518_odbc2.htm
> kannst du ein kurzes Video sehen was passiert.
Ich hab mir beides angeschaut, in der Tat nichts kompliziertes. Ich muss
gestehen, dass ich mit A02 kaum gearbeitet habe und noch weniger mit der
Kombination A02/SQL-BE.
> Nein, vom Rechner hängt es nicht ab, und ich denke auch nicht von der
> Accessversion, ich werde ausserdem weiterhin auch Access 2002
> unterstützen müssen (neben Access 2010).
Unter A03 und A2010, mit denen ich intensivst auf SQL 2005/2008/R2 arbeite,
kenne ich das Verhalten nicht. Es gibt zwar immer wieder mal ODBC Timeouts,
aber da sind die Ursachen meist erkennbar (schwache HW, schlechtes
DB-Design, schlechtes SQL usw) und relativ leicht zu beheben. Und bei A03
nicht zu vergessen, jenes unsaegliche SP3, mit dem alle moeglichen Bugs in
Verbindung mit SQL-BE kamen, fuer das es wiederum ein Hotfix brauchte.
Insofern wuerde ich dir trotzdem nahelegen, mal an einem anderen Rechner
bzw. aus einer anderen Access-Version zu probieren. Schau auch, ob das
letzte SP eingespielt ist, siehe http://www.donkarl.com?FAQ9.1 (Service
Pack 3 fuer Office XP) bzw. ob Windows aktuell ist.
Fuer den aktuellen Rechner solltest du mal den ODBC-Trace einschalten und
schauen, was im Fehlerfall so passiert.
Und zu guter letzt, falls das alles nix bringt: installier dir eine lokale
SQL Express Version und schau, ob damit der Fehler auch auftritt. Nicht,
dass da am Server jemand in der DB rummacht ;-)
alpw...@gmail.com wrote:
>
>> Zeig mal den Code.
> Ich habe dir unter:
> http://www.klbg.com/odbc/0a_Test.mdb
> die abgespeckte DB bereitgestellt, die gerade noch den Fehler reproduziert.
> Unter:
> http://www.klbg.com/odbc/20120518_odbc2.htm
> kannst du ein kurzes Video sehen was passiert.
gestehen, dass ich mit A02 kaum gearbeitet habe und noch weniger mit der
Kombination A02/SQL-BE.
> Nein, vom Rechner hängt es nicht ab, und ich denke auch nicht von der
> Accessversion, ich werde ausserdem weiterhin auch Access 2002
> unterstützen müssen (neben Access 2010).
kenne ich das Verhalten nicht. Es gibt zwar immer wieder mal ODBC Timeouts,
aber da sind die Ursachen meist erkennbar (schwache HW, schlechtes
DB-Design, schlechtes SQL usw) und relativ leicht zu beheben. Und bei A03
nicht zu vergessen, jenes unsaegliche SP3, mit dem alle moeglichen Bugs in
Verbindung mit SQL-BE kamen, fuer das es wiederum ein Hotfix brauchte.
Insofern wuerde ich dir trotzdem nahelegen, mal an einem anderen Rechner
bzw. aus einer anderen Access-Version zu probieren. Schau auch, ob das
letzte SP eingespielt ist, siehe http://www.donkarl.com?FAQ9.1 (Service
Pack 3 fuer Office XP) bzw. ob Windows aktuell ist.
Fuer den aktuellen Rechner solltest du mal den ODBC-Trace einschalten und
schauen, was im Fehlerfall so passiert.
Und zu guter letzt, falls das alles nix bringt: installier dir eine lokale
SQL Express Version und schau, ob damit der Fehler auch auftritt. Nicht,
dass da am Server jemand in der DB rummacht ;-)
alpw...@gmail.com
May 21, 2012, 2:20:34 AM5/21/12
to
Liebe Experten, lieber Peter,
Danke nochmal für die Unterstützung.
Jemand hat mich auf folgenden kb-Artikel aufmerksam gemacht:
http://support.microsoft.com/kb/302492
Dort wird genau das Problem beschrieben.
Ganz wie dort Beschrieben funktioniert es zwar nicht, ich muss auf Feldebene im After_Update Event ein Requery machen (und das wohl in allen Feldern des Subforms):
Private Sub Bemerkung_AfterUpdate()
Me.Requery
End Sub
Folgende 3 Möglichkeiten funktionieren übrigens nicht:
-) RunCommand acCmdSaveRecord
-) If Me.Dirty Then Me.Dirty = False
-) Me.Refresh
Zusatzfrrage:
Kann ich verhindern, dass der Cursor nach dem Requery immer in
1.Zeile, 1.Spalte springt? Ich nehme an, ich muss mir die Position merken und wieder zurückspringen.
Ich denke ich werde dafür ein neues Thema öffnen müssen.
LG, W
PS: Es ist mir bewusst, dass Acc2002 reichlich betagt ist, es sollen demnächst alle Arbeitsplätze auf Acc2010 umgestellt werden. Ich kann aber nicht ausschliessen, dass ein Nachzügler noch länger unter Acc2002 bleibt.
Danke nochmal für die Unterstützung.
Jemand hat mich auf folgenden kb-Artikel aufmerksam gemacht:
http://support.microsoft.com/kb/302492
Dort wird genau das Problem beschrieben.
Private Sub Bemerkung_AfterUpdate()
Me.Requery
End Sub
Folgende 3 Möglichkeiten funktionieren übrigens nicht:
-) RunCommand acCmdSaveRecord
-) If Me.Dirty Then Me.Dirty = False
-) Me.Refresh
Zusatzfrrage:
Kann ich verhindern, dass der Cursor nach dem Requery immer in
1.Zeile, 1.Spalte springt? Ich nehme an, ich muss mir die Position merken und wieder zurückspringen.
Ich denke ich werde dafür ein neues Thema öffnen müssen.
LG, W
PS: Es ist mir bewusst, dass Acc2002 reichlich betagt ist, es sollen demnächst alle Arbeitsplätze auf Acc2010 umgestellt werden. Ich kann aber nicht ausschliessen, dass ein Nachzügler noch länger unter Acc2002 bleibt.
Peter Doering
May 21, 2012, 3:25:45 AM5/21/12
to
Hallo,
alpw...@gmail.com wrote:
> Kann ich verhindern, dass der Cursor nach dem Requery immer in 1.Zeile,
> 1.Spalte springt? Ich nehme an, ich muss mir die Position merken und
> wieder zurückspringen.
http://www.donkarl.com?FAQ4.5
alpw...@gmail.com wrote:
> Kann ich verhindern, dass der Cursor nach dem Requery immer in 1.Zeile,
> 1.Spalte springt? Ich nehme an, ich muss mir die Position merken und
> wieder zurückspringen.
0 new messages