Daten werden nicht gespeichert ab ca. 2000 Zeichen

[Leuenberger Christian]

Ich kann die Daten nicht ändern oder speichern,
wenn mehr als ca. 2000 Zeichen in einem Memofeld sind.
(Neu erstellen mit mehr als 2000 Zeichen ist kein Problem, nur das
anschliessende Berabeiten)

Formular Übersicht

Treeview, Memofeld, ufo
Datenherkunft ist Snapshot


von diesem Formular aus wird das Eingabeformular geöffnet
DoCmd.OpenForm "frm_Eingabe", acNormal, ,"ID=" & Me!txt_ID, ,acDialog, False

Das Problem das ich so habe ist, ich kann die Daten nach dem Bearbeiten
nicht speichern.
Beim schliessen des Formulares habe ich:
DoCmd.RunCommand acCmdSaveRecord
das ergibt den Laufzeitfehler 3188

Aktualisieren nicht möglich, momentane Sperrung durch eine andere

Sitzung auf diesem Rechner<

ohne das SaveRecord, gibt es keine Fehlermeldung, aber die Daten werden
nicht geändert.

Ist das Übersichtsformular nicht geöffnet, funktioniert es.

Gruss
Christian

[Leuenberger Christian]

Eingestellt ist >keine Sperrungen<

Arbeite mit Access XP

Gruss
Christian

Hallo Christian,

Post by Leuenberger Christian
Ich kann die Daten nicht ändern oder speichern,
wenn mehr als ca. 2000 Zeichen in einem Memofeld sind.
(Neu erstellen mit mehr als 2000 Zeichen ist kein Problem, nur das
anschliessende Berabeiten)
Formular Übersicht
Treeview, Memofeld, ufo
Datenherkunft ist Snapshot
von diesem Formular aus wird das Eingabeformular geöffnet
DoCmd.OpenForm "frm_Eingabe", acNormal, ,"ID=" & Me!txt_ID, ,acDialog, False
Das Problem das ich so habe ist, ich kann die Daten nach dem Bearbeiten
nicht speichern.
DoCmd.RunCommand acCmdSaveRecord
das ergibt den Laufzeitfehler 3188

Aktualisieren nicht möglich, momentane Sperrung durch eine andere

Sitzung auf diesem Rechner<
ohne das SaveRecord, gibt es keine Fehlermeldung, aber die Daten werden
nicht geändert.
Ist das Übersichtsformular nicht geöffnet, funktioniert es.

welcher Wert ist bei Dir unter Extras / Optionen / Weitere
als Wert bei "Standard für Datensatzsperrung" ausgewählt?
CU

[Henry Habermacher]

Hallo Christian

Post by Leuenberger Christian
Formular Übersicht
Treeview, Memofeld, ufo
Datenherkunft ist Snapshot

*Snapshot* ist eigentlich für eingelesene Daten immer ReadOnly. Ändere das
mal auf Dynaset, dann sollten die Daten aktualisierbar sein.

Gruss
Henry

[Leuenberger Christian]

Das Eingabeformular ist auf Dynaset eingestellt.

Snapshot ist nur im Übersichtsformular (Ausgabe der Daten) eingestellt.

Gruss
Christian

Hallo Christian

Post by Leuenberger Christian
Formular Übersicht
Treeview, Memofeld, ufo
Datenherkunft ist Snapshot

*Snapshot* ist eigentlich für eingelesene Daten immer ReadOnly. Ändere
das mal auf Dynaset, dann sollten die Daten aktualisierbar sein.
Gruss
Henry

[Thomas Möller]

Hallo Christian,

Post by Leuenberger Christian
Ich kann die Daten nicht ändern oder speichern,
wenn mehr als ca. 2000 Zeichen in einem Memofeld sind.
(Neu erstellen mit mehr als 2000 Zeichen ist kein Problem, nur das
anschliessende Berabeiten)
Formular Übersicht
Treeview, Memofeld, ufo
Datenherkunft ist Snapshot
von diesem Formular aus wird das Eingabeformular geöffnet
DoCmd.OpenForm "frm_Eingabe", acNormal, ,"ID=" & Me!txt_ID, ,acDialog, False
Das Problem das ich so habe ist, ich kann die Daten nach dem Bearbeiten
nicht speichern.
DoCmd.RunCommand acCmdSaveRecord
das ergibt den Laufzeitfehler 3188

Aktualisieren nicht möglich, momentane Sperrung durch eine andere

Sitzung auf diesem Rechner<
ohne das SaveRecord, gibt es keine Fehlermeldung, aber die Daten werden
nicht geändert.
Ist das Übersichtsformular nicht geöffnet, funktioniert es.

welcher Wert ist bei Dir unter Extras / Optionen / Weitere
als Wert bei "Standard für Datensatzsperrung" ausgewählt?

CU

[Henry Habermacher]

Hallo Christian

Post by Leuenberger Christian
Das Problem das ich so habe ist, ich kann die Daten nach dem Bearbeiten
nicht speichern.
DoCmd.RunCommand acCmdSaveRecord
das ergibt den Laufzeitfehler 3188

Aktualisieren nicht möglich, momentane Sperrung durch eine andere

Sitzung auf diesem Rechner<

Was machst Du hinter dem Formular beim Form_AfterUpdate Ereignis?

Gruss
Henry

[Leuenberger Christian]

Das Problem liegt defintiv beim Ausgabeformular.
Dort ist kein AfterUpdate Ereignis.

Ich habe zum Test mal ein neues EingabeFormular erstellt. Solange in der
Ausgabe der Datensatz angezeigt wird, werden nach dem Bearbeiten, wenn
grösser 2000 Zeichen, die Daten nicht in Tabelle geschrieben.

Kleiner 2000 Zeichen ist kein Problem
Gruss
Christian

Hallo Christian

Post by Leuenberger Christian
Das Problem das ich so habe ist, ich kann die Daten nach dem Bearbeiten
nicht speichern.
DoCmd.RunCommand acCmdSaveRecord
das ergibt den Laufzeitfehler 3188

Aktualisieren nicht möglich, momentane Sperrung durch eine andere

Sitzung auf diesem Rechner<

Was machst Du hinter dem Formular beim Form_AfterUpdate Ereignis?
Gruss
Henry

[Oliver Straub]

Hallo!

Post by Leuenberger Christian
Treeview, Memofeld, ufo
Datenherkunft ist Snapshot

Das hört sich aber nicht so an, als müssten man jetzt wissen, wie das
Formular zusammengebaut ist.
Wofür das Memofeld, wofür das ufo, ...

Post by Leuenberger Christian
von diesem Formular aus wird das Eingabeformular geöffnet
DoCmd.OpenForm "frm_Eingabe", acNormal, ,"ID=" & Me!txt_ID, ,acDialog, False

wofür jetzt noch mal ein Eingabeformular, und warum ist das auf acDialog
geöffnet?

Der Hinweis mit den 2000 Zeichen macht auch keinen Sinn! Geht es etwa mit
1999 Zeichen?


Mach mal das acDialog weg und verwende die Form-Eigenschaft Modal
(gebunden). Kommt mir so vor, al s gäbe es da einen Zusammenhang, ansonsten
macht das alles keinen rechten Sinn (imo).


hth


Gruss
Oliver

[Leuenberger Christian]

Ich habe zum Test mal ein neues EingabeFormular erstellt. Solange in der
Ausgabe der Datensatz angezeigt wird, werden nach dem Bearbeiten, wenn
grösser 2000 Zeichen, die Daten nicht in Tabelle geschrieben.

Das Ufo dient dazu den Datensatz für den User als gelesen zu markieren

Kleiner 2000 Zeichen ist kein Problem
Gruss
Christian

Post by Oliver Straub
Hallo!

Post by Leuenberger Christian
Treeview, Memofeld, ufo
Datenherkunft ist Snapshot

Das hört sich aber nicht so an, als müssten man jetzt wissen, wie das
Formular zusammengebaut ist.
Wofür das Memofeld, wofür das ufo, ...

Post by Leuenberger Christian
von diesem Formular aus wird das Eingabeformular geöffnet
DoCmd.OpenForm "frm_Eingabe", acNormal, ,"ID=" & Me!txt_ID, ,acDialog, False

wofür jetzt noch mal ein Eingabeformular, und warum ist das auf acDialog
geöffnet?
Der Hinweis mit den 2000 Zeichen macht auch keinen Sinn! Geht es etwa mit
1999 Zeichen?
Mach mal das acDialog weg und verwende die Form-Eigenschaft Modal
(gebunden). Kommt mir so vor, al s gäbe es da einen Zusammenhang, ansonsten
macht das alles keinen rechten Sinn (imo).
hth
Gruss
Oliver

[Henry Habermacher]

Hallo Christian

Post by Leuenberger Christian
Ich habe zum Test mal ein neues EingabeFormular erstellt. Solange in der
Ausgabe der Datensatz angezeigt wird, werden nach dem Bearbeiten, wenn
grösser 2000 Zeichen, die Daten nicht in Tabelle geschrieben.
Das Ufo dient dazu den Datensatz für den User als gelesen zu markieren

Das sieht nach einem Bug in Access aus. Memofelder werden ja nicht in den
üblichen Record strukturen übermittelt (weil diese auf 2kB limitiert sind),
und auch nicht so abgelegt, sondern in speziellen Strukturen.
Wie es aussieht meint Access, dass es, wenn der Datensatz im Ausgabe
Formular angezeigt wird, dieser im Eingabeformular nicht gegeschrieben
werden soll. Bist Du sicher, dass das Ausgabeformular den Datensatz zu
dieser Zeit nicht gesperrt hat? Kontrolliere mal im Direktfenster über
? Forms("Ausgabeformular").Dirty
ob allenfalls irgendwas abgelaufen ist, das den DAtensatz verändert und
darum gesperrt hat.

Versuche auf jeden Fall auch mal die Datenbank zu reparieren und
komprimieren, Evt. hängst Du hier an einer entstehenden Memofeld Datenbank
Korruption. Leg' mal eine neue MDB an und importiere alle Objekte der
bestehenden in diese hinein. Wenn es dann immer noch nicht geht, dann wäre
es interessant, das mal live zu sehen. Falls möglich: Lösche alles aus der
MDB raus, was es nicht braucht, bis auf die Tabellen und die beiden
Formulare, denke ich. Versuche es dann nochmals zu reproduzieren. Wenn es
immer noch nicht geht, könntest Du diese MDB mal irgendwo zum Download
bereitstellen, damit wir das mal genauer anschauen können.

Gruss
Henry

[Leuenberger Christian]

Also Dirty gibt False zurück

Datenbank kann unter
http://www.famleu.ch/load.php?name=MFMedia&mid=22

herutergeladen werden. Starten mit dem autoexec_1 Macro

Gruss
Christian

Hallo Christian

Post by Leuenberger Christian
Ich habe zum Test mal ein neues EingabeFormular erstellt. Solange in der
Ausgabe der Datensatz angezeigt wird, werden nach dem Bearbeiten, wenn
grösser 2000 Zeichen, die Daten nicht in Tabelle geschrieben.
Das Ufo dient dazu den Datensatz für den User als gelesen zu markieren

Das sieht nach einem Bug in Access aus. Memofelder werden ja nicht in
den üblichen Record strukturen übermittelt (weil diese auf 2kB limitiert
sind), und auch nicht so abgelegt, sondern in speziellen Strukturen.
Wie es aussieht meint Access, dass es, wenn der Datensatz im Ausgabe
Formular angezeigt wird, dieser im Eingabeformular nicht gegeschrieben
werden soll. Bist Du sicher, dass das Ausgabeformular den Datensatz zu
dieser Zeit nicht gesperrt hat? Kontrolliere mal im Direktfenster über
? Forms("Ausgabeformular").Dirty
ob allenfalls irgendwas abgelaufen ist, das den DAtensatz verändert und
darum gesperrt hat.
Versuche auf jeden Fall auch mal die Datenbank zu reparieren und
komprimieren, Evt. hängst Du hier an einer entstehenden Memofeld
Datenbank Korruption. Leg' mal eine neue MDB an und importiere alle
Objekte der bestehenden in diese hinein. Wenn es dann immer noch nicht
Lösche alles aus der MDB raus, was es nicht braucht, bis auf die
Tabellen und die beiden Formulare, denke ich. Versuche es dann nochmals
zu reproduzieren. Wenn es immer noch nicht geht, könntest Du diese MDB
mal irgendwo zum Download bereitstellen, damit wir das mal genauer
anschauen können.
Gruss
Henry

[Peter Doering]

Hallo,

Post by Leuenberger Christian
Datenbank kann unter
http://www.famleu.ch/load.php?name=MFMedia&mid=22
herutergeladen werden. Starten mit dem autoexec_1 Macro

Es liegt am Treeview Control in frm_User. Um die Ursache nachzuvollziehen,
probier mal folgendes:

- tbl_Haupttabelle oeffnen.
- frm_User oeffnen.
- im Treeview <=2000 auswaehlen.
- zur Tabelle wechseln, MSG_Text aendern, geht.
- im Treeview >=2000 auswaehlen.
- zur Tabelle wechseln, MSG_Text aendern, geht NICHT.

Wenn der Datensatz im Treeview-Ctrl. nicht ausgewaehlt ist, klappt der
Update. Loesung hab ich noch keine.

Gruss - Peter

[Josef Poetzl]

Hallo!

Post by Peter Doering

Post by Leuenberger Christian
Datenbank kann unter
http://www.famleu.ch/load.php?name=MFMedia&mid=22
herutergeladen werden. Starten mit dem autoexec_1 Macro

Es liegt am Treeview Control in frm_User. Um die Ursache nachzuvollziehen,
- tbl_Haupttabelle oeffnen.
- frm_User oeffnen.
- im Treeview <=2000 auswaehlen.
- zur Tabelle wechseln, MSG_Text aendern, geht.
- im Treeview >=2000 auswaehlen.
- zur Tabelle wechseln, MSG_Text aendern, geht NICHT.
Wenn der Datensatz im Treeview-Ctrl. nicht ausgewaehlt ist, klappt der
Update. Loesung hab ich noch keine.

Ich sah mir das auch an und löschte mal alles raus, was nicht
notwendig ist. Übrig blieb ein Formular mit einem Textfeld und einer
Schaltfläche zum Öffnen des Bearbeitungsformulars.

Sobald das Textfeld an das Memofeld gebunden ist, tritt der Fehler
auf.
Verwendet man ein ungebundenes Textfeld und holt den Wert dafür über
DLookup aus dem Datensatz, wird nichts gesperrt.

Verkürztes Beispiel zum Testen:
http://access.joposol.com/download/MemofeldProblem.zip


mfg
Josef

[Peter Doering]

Hallo,

Post by Josef Poetzl

Post by Peter Doering

Post by Leuenberger Christian
Datenbank kann unter
http://www.famleu.ch/load.php?name=MFMedia&mid=22
herutergeladen werden. Starten mit dem autoexec_1 Macro

Es liegt am Treeview Control in frm_User. Um die Ursache nachzuvollziehen,
- tbl_Haupttabelle oeffnen.
- frm_User oeffnen.
- im Treeview <=2000 auswaehlen.
- zur Tabelle wechseln, MSG_Text aendern, geht.
- im Treeview >=2000 auswaehlen.
- zur Tabelle wechseln, MSG_Text aendern, geht NICHT.
Wenn der Datensatz im Treeview-Ctrl. nicht ausgewaehlt ist, klappt der
Update. Loesung hab ich noch keine.

Ich sah mir das auch an und löschte mal alles raus, was nicht
notwendig ist. Übrig blieb ein Formular mit einem Textfeld und einer
Schaltfläche zum Öffnen des Bearbeitungsformulars.
Sobald das Textfeld an das Memofeld gebunden ist, tritt der Fehler
auf.
Verwendet man ein ungebundenes Textfeld und holt den Wert dafür über
DLookup aus dem Datensatz, wird nichts gesperrt.
http://access.joposol.com/download/MemofeldProblem.zip

Ok, die Textbox hinter dem Rechteck hatte ich nicht gesehen und deshalb den
Treeview in Verdacht. Wenn man die ControlSource aus txt_Text loescht,
funktioniert der Update.

Gruss - Peter

[Josef Poetzl]

Hallo!
[...]

Post by Peter Doering

Post by Josef Poetzl
Sobald das Textfeld an das Memofeld gebunden ist, tritt der Fehler
auf.
Verwendet man ein ungebundenes Textfeld und holt den Wert dafür über
DLookup aus dem Datensatz, wird nichts gesperrt.
http://access.joposol.com/download/MemofeldProblem.zip

Ok, die Textbox hinter dem Rechteck hatte ich nicht gesehen und deshalb den
Treeview in Verdacht. Wenn man die ControlSource aus txt_Text loescht,
funktioniert der Update.

Noch ein paar Tests:
Es reicht bereits ein Zugriff über das Formular-Recordset auf das
Memofeld aus, um die Sperre zu aktivieren.
| me!UngebundenesSteuerelement.Value = me.recordset.fields("MemoFeld")

Auslesen über ein zusätzlich geöffnetes Recordset ist möglich.

Wenn man das Formular an ein ADODB-Recordset bindet, gibt es auch
keine Sperre.

Die kritsche Anzahl von Zeichen ist bei mir 2036. Über 2036 Zeichen im
Memofeld kommt es zur Sperre.
Anm.: getestet unter AcXP

Post by Peter Doering
Das sieht nach einem Bug in Access aus.

Ich finde, das trifft es ganz gut. ;-)


mfg
Josef

[Leuenberger Christian]

Besten dank für die Hilfe.
Ich bin froh, das es nicht an meiner Arbeit liegt.
Habe es nach deinem Vorschlag mit DLookup gelöst.

Gruss
Christian

Post by Oliver Straub
Hallo!
[...]

Post by Peter Doering

Post by Josef Poetzl
Sobald das Textfeld an das Memofeld gebunden ist, tritt der Fehler
auf.
Verwendet man ein ungebundenes Textfeld und holt den Wert dafür über
DLookup aus dem Datensatz, wird nichts gesperrt.
http://access.joposol.com/download/MemofeldProblem.zip

Ok, die Textbox hinter dem Rechteck hatte ich nicht gesehen und deshalb den
Treeview in Verdacht. Wenn man die ControlSource aus txt_Text loescht,
funktioniert der Update.

Es reicht bereits ein Zugriff über das Formular-Recordset auf das
Memofeld aus, um die Sperre zu aktivieren.
| me!UngebundenesSteuerelement.Value = me.recordset.fields("MemoFeld")
Auslesen über ein zusätzlich geöffnetes Recordset ist möglich.
Wenn man das Formular an ein ADODB-Recordset bindet, gibt es auch
keine Sperre.
Die kritsche Anzahl von Zeichen ist bei mir 2036. Über 2036 Zeichen im
Memofeld kommt es zur Sperre.
Anm.: getestet unter AcXP

Post by Peter Doering
Das sieht nach einem Bug in Access aus.

Ich finde, das trifft es ganz gut. ;-)
mfg
Josef

[Oliver Straub]

Hallo!

Post by Josef Poetzl
Die kritsche Anzahl von Zeichen ist bei mir 2036. Über 2036 Zeichen im
Memofeld kommt es zur Sperre.

Da ich das Fehlverhalten noch etwas genauer Beschreiben kann, mache ich das
doch einfach noch:

[Annäherung an das Dateiformat für Jet 4 (A00-A03)]
Eine Mdb-Datei besteht aus Segmenten fester Größe. Ein Segment wird Page
genannt und besteht aus 4096 Bytes. (Die Größe einer Mdb-Datei entspricht
also immer einem vielfachen von 4096 Bytes.) Die Pages identifizieren sich
selber, es gibt kein Inhaltsverzeichnis (wie etwa ein FAT). Das erste Byte
einer Page legt den grundsätzlichen Page-Typ fest.
Tabellendefinitionen werden in TDEF-Pages und Daten in Data-Pages
gespeichert. Die Daten werden dabei Zeilenweise in Row-Records gespeichert,
die jeweils die Daten der Spalten einer Zeile beinhalten. Ein solcher
Row-Record besteht aus Header, Spalten fester Größe, Spalten variabler
Größe, Infos zu den Spalten variabler Größe und den Spalten für Null-Werte
(Ja/Nein-Felder) (1 Byte pro 8).
Ein Feld vom Datentyp Text ist eine Spalte variabler Größe. Der Inhalt wird
als String direkt im Row-Record gespeichert. Felder vom Datentyp Memo sind
ebenfalls Spalten variabler Größe, die aber auf 3 verschiedene Arten
gespeichert werden. Bis zu einer bestimmten Größe wird der Feldinhalt auch
direkt im Row-Record gespeichert. Bei größerem Inhalt, werden die Daten in
einer weiteren Data-Page vom Untertyp LVAL abgelegt.
Die Daten der Memo-Spalten besitzen im Gegensatz zu denen der Text-Spalten
einen Header. Dieser Header gibt Auskunft über die Größe und den Speicherort
des Feldinhalts. Ist der Feldinhalt zu groß, um auf nur einer LVAL-Page
ausgelagert zu werden, dann werden eben weitere n-LVAL-Pages verwendet. Zu
Beginn eines Daten-Records in einer LVAL-Page ist vermerkt, ob, bzw. auf
welcher LVAL-Page die nächsten Daten der Memo-Spalte gespeichert sind.

Jet unterscheidet somit 3 verschiedene Speicherarten für Memo-Spalten:
1. Die Daten werden direkt im Row-Record gespeichert.
2. Die Daten sind in einer LVAL-Page gespeichert.
3. Die Daten sind in n-LVAL-Pages gespeichert.

Zum Speichern werden 2 Bytes pro Zeichen benötigt. Da nach Abzug der
Headerdaten pro LVAL-Page noch 4072 Bytes zur Verfügung stehen, können bis
zu 2036 Zeichen auf einer LVAL-Page gespeichert werden.

Zu dem Fehler vom OP lässt sich also sagen, dass das Memo-Feld gesperrt
wird, sobald der Inhalt auf n-LVAL-Pages gespeichert ist. Der
Eingangszustand ist dabei entscheidend. Sind erst <=2036 Zeichen erfasst,
ist das Feld nicht gesperrt und man kann eine beliebig große Anzahl von
Zeichen (auch >2036) speichern. Ab 2037 Zeichen ist dann (min.) eine weitere
LVAL-Page angelegt und die Daten sind nach einem Aufruf wieder komplett
gesperrt.

Per Hex-Editor konnte ich das alles nachvollziehen, dabei hab ich noch
gesehen, dass das Flag, das im Memo-Header die Memo-Speicherart
kennzeichnet, dabei keine Rolle zu spielen scheint, da es nach einer
Datenreduktion nicht zurückgesetzt wird, und die Daten aber trotzdem ab 2036
Zeichen wieder bearbeitbar sind.


Bug oder Feature? Man kann's schlecht sagen! :-))


Gruss
Oliver

[Josef Poetzl]

Hallo!

Post by Oliver Straub

Post by Josef Poetzl
Die kritsche Anzahl von Zeichen ist bei mir 2036. Über 2036 Zeichen im
Memofeld kommt es zur Sperre.

Da ich das Fehlverhalten noch etwas genauer Beschreiben kann, mache ich das

Danke!

Post by Oliver Straub
[Annäherung an das Dateiformat für Jet 4 (A00-A03)]

[...]

Post by Oliver Straub
Zu dem Fehler vom OP lässt sich also sagen, dass das Memo-Feld gesperrt
wird, sobald der Inhalt auf n-LVAL-Pages gespeichert ist. Der
Eingangszustand ist dabei entscheidend. Sind erst <=2036 Zeichen erfasst,
ist das Feld nicht gesperrt und man kann eine beliebig große Anzahl von
Zeichen (auch >2036) speichern. Ab 2037 Zeichen ist dann (min.) eine weitere
LVAL-Page angelegt und die Daten sind nach einem Aufruf wieder komplett
gesperrt.
Per Hex-Editor konnte ich das alles nachvollziehen, dabei hab ich noch
gesehen, dass das Flag, das im Memo-Header die Memo-Speicherart
kennzeichnet, dabei keine Rolle zu spielen scheint, da es nach einer
Datenreduktion nicht zurückgesetzt wird, und die Daten aber trotzdem ab 2036
Zeichen wieder bearbeitbar sind.
Bug oder Feature? Man kann's schlecht sagen! :-))

Ich würde es als "unerwartetes Verhalten" einstufen. :-)
Zumindest finde ich es ungewöhnlich, dass ein Lesezugriff die
Bearbeitung sperrt.

Anm.:
Bei Verwendung eines ADODB-Rs für das "Lese-Form" gibt es auch keine
Sperre.
Ein ADODB-Rs als Edit-Grundlage hilft nicht. Die Sperre durch das
DAO-Lesen bleibt trotzdem.

Ist das nun ein Jet oder ein DAO-Problem? Ich würde auf DAO tippen.
=>
Ein Test nur mit DAO-Recordsets erzeugt allerdings auch kein Problem.
Prinzip:
1. rs1 öffnen und Wert vom Memofeld auslesen
2. rs2 öffnen und Memofeld bearbeiten
=> läuft ohne Probleme

Also wird es vermutlich am Formular-Recordset liegen bzw. an dem was
das Form aus dem DAO-Recordset macht. (Die Übergabe eines selbst
geöffneten DAO-Rs nutzt nämlich auch nichts.)


mfg
Josef

[Oliver Straub]

Hallo Josef,

Post by Josef Poetzl
Bei Verwendung eines ADODB-Rs für das "Lese-Form" gibt es auch keine
Sperre.

heisst das, wenn me.recordset ein ADODB-rs ist und sonst alles gleich
bleibt, geht es?

Post by Josef Poetzl
Ist das nun ein Jet oder ein DAO-Problem? Ich würde auf DAO tippen.
=>
Ein Test nur mit DAO-Recordsets erzeugt allerdings auch kein Problem.
1. rs1 öffnen und Wert vom Memofeld auslesen
2. rs2 öffnen und Memofeld bearbeiten
=> läuft ohne Probleme
Also wird es vermutlich am Formular-Recordset liegen bzw. an dem was
das Form aus dem DAO-Recordset macht. (Die Übergabe eines selbst
geöffneten DAO-Rs nutzt nämlich auch nichts.)

Wenn man einfach das Textfeld aus dem "Lese-Form" entfernt, sind die Daten
im "Edit-Form" nicht mehr gesperrt. Die Bindung der Memo-Spalte an das
Textfeld bewirkt also die Sperre. Das kann man sich auch irgendwie
vorstellen. Das Textfeld selber muss ja die Daten beim Scrollen unter
Kontrolle haben, vielleicht wird da immer nur max 1 LVAL-Page im Speicher
gehalten und weitere Daten erst bei Bedarf geladen. Das hat klare
Performance-Vorteile beim Anzeigen der DS im Formular. Aus irgendeinem
Grund, wird die Memo-Spalte dann gesperrt. Ich denke nicht, dass das ein Bug
ist, sondern eher ein konzeptionelles Muss (Bereich geringster Unschärfe).
(Ist aber natürlich nur so ne Idee).

Gruss
Oliver

[Josef Poetzl]

Hallo!

Post by Oliver Straub

Post by Josef Poetzl
Bei Verwendung eines ADODB-Rs für das "Lese-Form" gibt es auch keine
Sperre.

heisst das, wenn me.recordset ein ADODB-rs ist und sonst alles gleich
bleibt, geht es?

Ja. Wobei mit einem ADODB-Rs kaum etwas gleicht bleibt, auch wenn der
Code dahinter keines besonderen Änderungen erfordert. Das Formular
wird im Hintergrund einem ADP-Formular sehr ähnlich. (Aktiviere einmal
beim Formular die Eigenschaften in der Formular-Ansicht. Dann wirst du
Eigenschaften sehen, die in eine üblichem mdb-Form nicht angezeigt
werden.)

Dieses Szenario mit dem ADODB-Rs ist auch in der Beispiel-mdb
enthalten.

[...]

Post by Oliver Straub
Wenn man einfach das Textfeld aus dem "Lese-Form" entfernt, sind die Daten
im "Edit-Form" nicht mehr gesperrt. Die Bindung der Memo-Spalte an das
Textfeld bewirkt also die Sperre.

Wenn du das Textfeld ungebunden machst und die Daten vom
Form-Recordset holst, ist wieder gesperrt.

| Me.UngebundenesTextfeld.Value = me.recordset.fields("MemoFeld")

Ein DS wird gesperrt, sobald einmal auf das Memofeld im Form-Recordset
zugegriffen wurde. (Bindung an Steuerelement ist dabei nicht
erforderlich)
Durch einen DS-Wechsel könnte man die Sperre umgehen:
| Me.UngebundenesTextfeld.Value = me.recordset.fields("MemoFeld")
| Me.Recordset.MoveNext
| Me.Recordset.MovePrevious

Anm.: diese Variante ist natürlich kein Lösungsansatz, sondern soll
nur das Verhalten zeigen.


mfg
Josef

[Oliver Straub]

Hallo!

Post by Josef Poetzl
Wenn du das Textfeld ungebunden machst und die Daten vom
Form-Recordset holst, ist wieder gesperrt.
| Me.UngebundenesTextfeld.Value = me.recordset.fields("MemoFeld")
Ein DS wird gesperrt, sobald einmal auf das Memofeld im Form-Recordset
zugegriffen wurde. (Bindung an Steuerelement ist dabei nicht
erforderlich)
| Me.UngebundenesTextfeld.Value = me.recordset.fields("MemoFeld")
| Me.Recordset.MoveNext
| Me.Recordset.MovePrevious

Dann würde ich das Ganze doch langsam als Bug bezeichnen. ;-) Heißt das
dann, dass Memofelder ab 2036 Zeichen nicht Mehrplatzfähig sind? Wofür
eigentlich auch? Sollen zwei Leute gleichzeitig den Text in einem Memofeld
bearbeiten? Einer unten der Andere oben? :-)) Ich denke mal, auf eine
solche Funktionalität kann man zur Not schon verzichten. Ich jedenfalls.;-))


Gruss
Oliver

[Oliver Straub]

Jetzt hab ich das doch noch mal bei einer Anwendung von mir im Netz getestet
und es ist schon etwas ärgerlich. Sobald ein Client den DS mit einem
entsprechend langem Memo im Textfeld anwählt, ist das Feld beim anderen
Client gesperrt. Ohne Undo kommt der gar nicht mehr aus dem DS raus. Hm,
scheint mir irgendwie doch eine peinliche Wissenslücke zu sein, dieses
Problem nicht gekannt zu haben, aber das war mir bisher entgangen. Der
Unterschied ist ja nicht so groß, statt bearbeitete, sind angezeigte "DS"
gesperrt. Ich hab nicht viel mit langen Texten zutun, drum werde ich nicht
drauf reagieren. Zur Not vielleicht:

Beim Anzeigen.
if Len(Nz(me![Memo]))>2036) then
me![Memo]=me![Memo]
me.dirty = false
endif

Ingried

[Josef Poetzl]

Hallo!

... Der
Unterschied ist ja nicht so groß, statt bearbeitete, sind angezeigte "DS"
gesperrt.

Dass ein Datenfeld nicht geändert werden kann, nur weil jemand anders
dessen Inhalt liest, entspricht nicht meiner Erwartungshaltung.
Es scheint aber kein besonderes Problem zu sein, sonst wäre das
bestimmt schon früher aufgefallen. :-)
(Das Problem tritt bereits unter Ac97 auf.)

Ich hab nicht viel mit langen Texten zutun, drum werde ich nicht
Beim Anzeigen.
if Len(Nz(me![Memo]))>2036) then
me![Memo]=me![Memo]
me.dirty = false
endif

Das würde auch nicht helfen.


mfg
Josef

[Oliver Straub]

Hallo!

Post by Josef Poetzl
Dass ein Datenfeld nicht geändert werden kann, nur weil jemand anders
dessen Inhalt liest, entspricht nicht meiner Erwartungshaltung.
Es scheint aber kein besonderes Problem zu sein, sonst wäre das
bestimmt schon früher aufgefallen. :-)
(Das Problem tritt bereits unter Ac97 auf.)

Das Problem ist schon ärgerlich. Es werden aber nur die Memofelder gesperrt
und nicht der ganze DS, sonst wäre es richtig ärgerlich.
Schön ist das nicht, vor allem, wenn es nur daran liegt, dass ein
übermüdeter MS-Programmierer nach dem Einlesen der Daten eines Memofeldes
mit Speichervariante 3, einfach vergessen hat, die Sperre des Feldes wieder
aufzuheben. Es scheint mir doch eindeutig ein reiner Bug zu sein. Wunder
mich nur, dass das nie korrigiert wurde, wenn es ansonsten keine Problem
gibt.

Post by Josef Poetzl

Post by Oliver Straub
Ich hab nicht viel mit langen Texten zutun, drum werde ich nicht
Beim Anzeigen.
if Len(Nz(me![Memo]))>2036) then
me![Memo]=me![Memo]
me.dirty = false
endif

Das würde auch nicht helfen.

Stimmt, so geht's nicht. Es geht aber so ähnlich (das hatte ich getestet):

Im User-Fenster vom Christian hab ich Beim Anzeigen:
Me![Geschuetzt] = Me![Geschuetzt]
Und bevor das Edit-Fenster geöffnet wird hab ich das me.dirty=false

Damit lassen sich dann auch die langen Texte bearbeiten.

Interessant, dass ein dirty=false im Current-Event noch nicht die Sperre
aufhebt.

Für eine echte Lösung würde ich natürlich erst mal richtig testen, aber mir
würde eh ein Variante über den Timer-Event vorschweben. Einmal nach einer
Sekunde pro DS wird dann die Dummy-Zuweisung und das dirty=false ausgeführt
werden (wenn memo>2036). Das erscheint mir (adhoc!?) eine brauchbare Lösung
seien zu können.



Gruss
Oliver

[Leuenberger Christian]

Hallo
habe mal meine Datenbanken überprüft.
habe in einer anderen genau das selbe Phänomen,
allerdings ist dort ein Listenfeld zur Auswahl eingesetzt.


Gruss
Christian

Post by Peter Doering
Hallo,

Post by Leuenberger Christian
Datenbank kann unter
http://www.famleu.ch/load.php?name=MFMedia&mid=22
herutergeladen werden. Starten mit dem autoexec_1 Macro

Es liegt am Treeview Control in frm_User. Um die Ursache nachzuvollziehen,
- tbl_Haupttabelle oeffnen.
- frm_User oeffnen.
- im Treeview <=2000 auswaehlen.
- zur Tabelle wechseln, MSG_Text aendern, geht.
- im Treeview >=2000 auswaehlen.
- zur Tabelle wechseln, MSG_Text aendern, geht NICHT.
Wenn der Datensatz im Treeview-Ctrl. nicht ausgewaehlt ist, klappt der
Update. Loesung hab ich noch keine.
Gruss - Peter

[Oliver Straub]

Hallo Christian,

Post by Leuenberger Christian
Datenbank kann unter
http://www.famleu.ch/load.php?name=MFMedia&mid=22

das Problem passt zum Programm, es wirkt irgendwie Außerirdisch. Hoffe Du
bist nicht vom Schweizer Geheimdienst und ich hab mir jetzt einen
Kantonstrojaner eingefangen. :-)



Auf Code-Ebene sieht das Ganze so aus, als würdest Du es hassen. Benutze
doch wenigstens die Tabulatortaste und mach mal ein paar Absätze
zwischendrin.



Ich finde das Eingabefenster ist komplett überflüssig. Die Änderungen sollte
der User gleich im "User-Form" machen. Nach Klick auf den Button wird das TF
zur Bearbeitung freigestellt und entspr. weitere Controlls (Zuordnung)
sichtbar gemacht. Wüsste nicht, warum Du das in einem extra Fenster machen
müsstest.





Gruss

Oliver

[Thomas Möller]

Hallo Christian,

Post by Oliver Straub
Auf Code-Ebene sieht das Ganze so aus, als würdest Du es hassen. Benutze
doch wenigstens die Tabulatortaste und mach mal ein paar Absätze
zwischendrin.

zumindest für die Einrückungen könnte ich ein kleines Tool empfehlen,
den SmartIndenter:
http://www.oaltd.co.uk/Indenter/Default.htm
(Link in einer Zeile)

HTH

[Josef Poetzl]

Hallo!

Post by Thomas Möller

Post by Oliver Straub
Auf Code-Ebene sieht das Ganze so aus, als würdest Du es hassen. Benutze
doch wenigstens die Tabulatortaste und mach mal ein paar Absätze
zwischendrin.

zumindest für die Einrückungen könnte ich ein kleines Tool empfehlen,
http://www.oaltd.co.uk/Indenter/Default.htm
(Link in einer Zeile)

Wenn wir schon beim Empfehlen sind:
Generell für VBA-Code kann ich den "TM VBA-Inspector" empfehlen.
Gibt es unter http://www.team-moeller.de/

mfg
Josef

[Josef Poetzl]

Hallo!

Post by Leuenberger Christian
Ich kann die Daten nicht ändern oder speichern,
wenn mehr als ca. 2000 Zeichen in einem Memofeld sind.
(Neu erstellen mit mehr als 2000 Zeichen ist kein Problem, nur das
anschliessende Berabeiten)

[...]

Post by Leuenberger Christian
DoCmd.RunCommand acCmdSaveRecord
das ergibt den Laufzeitfehler 3188

Aktualisieren nicht möglich, momentane Sperrung durch eine andere
Sitzung auf diesem Rechner<

ohne das SaveRecord, gibt es keine Fehlermeldung, aber die Daten werden
nicht geändert.
Ist das Übersichtsformular nicht geöffnet, funktioniert es.

Zur Sicherheit nachgefragt:
Frontend und Backend sind mdb-Dateien?

mfg
Josef

[Leuenberger Christian]

Es sind mdb-dateien

Post by Oliver Straub
Hallo!

Post by Leuenberger Christian
Ich kann die Daten nicht ändern oder speichern,
wenn mehr als ca. 2000 Zeichen in einem Memofeld sind.
(Neu erstellen mit mehr als 2000 Zeichen ist kein Problem, nur das
anschliessende Berabeiten)

[...]

Post by Leuenberger Christian
DoCmd.RunCommand acCmdSaveRecord
das ergibt den Laufzeitfehler 3188

Aktualisieren nicht möglich, momentane Sperrung durch eine andere
Sitzung auf diesem Rechner<

ohne das SaveRecord, gibt es keine Fehlermeldung, aber die Daten werden
nicht geändert.
Ist das Übersichtsformular nicht geöffnet, funktioniert es.

Frontend und Backend sind mdb-Dateien?
mfg
Josef