Dokument lässt sich nicht abspeichern

[Aladdin Sane]

Hallo,

ich habe eine eigene Datenbank und darin im Laufe der letzten Monate diverse Dokumente derselben Maske
angelegt.
Nun tauchen hin und wieder (momentan drei) Dokumente auf, die sich nicht ändern lassen, bzw. wo die Änderung
nicht gespeichert wird.

Ich ändere ein beliebiges Feld und drücke Strg-S oder einen entsprechenden Button.
Die Änderung beleibt im Frontend bestehen. Wenn ich das Dokument schließe und neu öffne sind die Änderungen futsch.

Im Querysave ist nichts, was so ein verhalten erklärt.
Fast alle übrigen Dokumente lassen sich speichern...


Weiß jemand Rat?

Gruß
pASCAL

[pete_bla]

Hi,

Saveoptions = "0" drin ?

Gruss, Pete(r)

[Aladdin Sane]

Ja.
So steht es jedenfalls in den Dokument-Eigenschaften.

Ich habe dann mal ein gleichnamiges Feld angelegt und die "0" gelöscht.
Dann geht es.

Wann wird denn "Save Options = 0" gesetzt?
Bei compute_with_form?


danke erstmal und Gruß
pASCAL

[pete_bla]

Hi,

SaveOptions = "0" ist ein beliebtes mittel um ein "Speichern" und die "wollen Sie Speichern" abfrage zu unterbinden.
Ein STRG+S oder "Datei/Speichern" oder "speichern mit der Diskette" (alles UI) wird dann nicht vorgenommen.

Wo das SaveOptions in Deiner Anwendung herkommt kann ich wirklich nicht sagen
- da ich nicht weiss was es für eine Anwendung ist!

Wenn Du mehr infos gibst, können wir Dir dabei eventuell helfen. 

Gruss, Pete(r)

[guesswho]

Pascal,

die berechneten Items werden von oben links nach unten rechts berechnet.

Das "untere" überschreibt in deiner Form das vorherige Item, weil es später berechnet wird.

Deshalb muss man bei der Entwicklung auch ein bisschen darauf achten, wo (oben oder unten) man hidden Items einbaut...

Zwei Items mit gleichem Namen: das "spätere" gewinnt eh, brauchts deshalb nicht...
Jo

[pete_bla]

Hä bin ich schon wieder falsch gestrickt?

die berechneten Items werden von oben links nach unten rechts berechnet.

Das "untere" überschreibt in deiner Form das vorherige Item, weil es später berechnet wird.

Deshalb muss man bei der Entwicklung auch ein bisschen darauf achten, wo (oben oder unten) man hidden Items einbaut...

Zwei Items mit gleichem Namen: das "spätere" gewinnt eh, brauchts deshalb nicht...
Jo

muss wohl mal Layer8 auf suspend setzen ... 

Gruss, Pete(r)

[guesswho]

Pete(r),

nein, ich hab dir nicht widersprochen, du hast doch völlig recht. Die (räumliche) Anordnung der Items in der Form gilt aber auch.

Sorry btw: Zwei Items mit selbem Namen kann das gar nicht geben... Aber zwei Felder mit verschiedenen Namen, die das gleiche Item befüllen, dann greift das "später" berechnete. 

Jo

[koehlerbv]

Sorry btw: Zwei Items mit selbem Namen kann das gar nicht geben...

Doch, natürlich und ohne weiteres und das kommt auch häufig vor. Was Du meinst, sind Felder 

Und wenn Pascal jetzt ein Feld namens SaveOptions anlegen konnte, dann liegt es nahe, dass er vorher in einer Version der DB schon einmal ein Feld namens "SaveOptions" "ausprobiert" hat, und damit wurde das Item im Dokument gespeichert und wirkt da jetzt fröhlich weiter. Von alleine ist das Item dort ja nicht aufgetaucht 

Bernhard

[pete_bla]

 
@Jo:
jetzt - so kein kurzer büroschlaf bringt doch was ...
jetzt ists klar auf was Du raus wolltest... als wiederspruch hab ichs auch nicht gesehen.
Dachte nur Du siehst da mehr Infos zur DB von Pascal als ich ...

@PASCAL:
gerne gibts mehr Antwort, wenn Du uns mehr INFO gibst
(DB-template, Eigentenwicklung & Code...)

SaveOptions kann ein Feld, berechnet sein,
in irgend einer aktion über eine Funktion "gesetzt"=0 und "aufgehoben"<>0 oder deleted werden.
Meist gibst beim Öffnen des Dokuments eine Aktion die es setzt (postopen....)
und im "Save-Button" (z.B. der beim Erstellen verwendet wird)
igendwas, dass das Feld Saveoptions ändert.

Aber eigentlich sollte eine normale Anwendung auch STRG+S verkraften, man klickt sich ja sonst den Wolf.
Oder aber irgendeinen Hinweis darauf geben, dass nichts gespeichert wird!

Gruss, Pete(r)