Recordset nur in RAM erstellen / A00
Jens Tönsing
ich möchte ein Endlosformular so programmieren, daß der User darin Daten
eintragen kann. Erst wenn das Formular geschlossen wird, soll der User
gefragt werden, ob er die Daten speichern möchte. Es sollen also erst hier
die Datensätze in die eigendliche Tabelle schreiben.
Ich könnte zwar eine temporäre Tabelle erstellen und den User dort die Daten
eingeben lassen. Ich bin mir aber nicht sicher, ob dies wirklich die
sauberste Lösung ist.
Gibt es eine Möglichkeit, die Tabelle nur im Ram zu erstellen und dort mein
Endlosformular drauf basieren zu lassen?
Danke,
Jens
--
Bitte schickt mir keine Kopien eurer Postings per EMail!
Peter Steimann
"Jens Tönsing" <toen...@gmx.de> schrieb im Newsbeitrag
news:uaAQMnr...@cppssbbsa02.microsoft.com...
> Hallo,
>
> ich möchte ein Endlosformular so programmieren, daß der User darin Daten
> eintragen kann. Erst wenn das Formular geschlossen wird, soll der User
> gefragt werden, ob er die Daten speichern möchte. Es sollen also erst hier
> die Datensätze in die eigendliche Tabelle schreiben.
> Ich könnte zwar eine temporäre Tabelle erstellen und den User dort die
Daten
> eingeben lassen. Ich bin mir aber nicht sicher, ob dies wirklich die
> sauberste Lösung ist.
würd ich vermeiden wegen dem lagerhauseffekt
> Gibt es eine Möglichkeit, die Tabelle nur im Ram zu erstellen und dort
mein
> Endlosformular drauf basieren zu lassen?
nein. du kannst aber beim datensatzwechsel in einer form mit oldvalue
arbeiten und so die alten werte behalten. im endlos-formualr bleibt
allerding nur die temporäre tabelle.
gruss
peter
Frederic Luchting
: ich möchte ein Endlosformular so programmieren, daß der User darin
Daten
: eintragen kann. Erst wenn das Formular geschlossen wird, soll der
User
: gefragt werden, ob er die Daten speichern möchte. Es sollen also
erst hier
: die Datensätze in die eigendliche Tabelle schreiben.
:...
: Gibt es eine Möglichkeit, die Tabelle nur im Ram zu erstellen und
dort mein
: Endlosformular drauf basieren zu lassen?
Ich weiß nicht ob das Deine Wünsche befriedigt aber es ist sicher ein
interessanter Ansatz. (Nicht Tabelle im RAM erstellen sondern
Recordset von seiner Verbindung lösen und erst am Ende in
die Tabelle schreiben)
Private Sub btnCmd_Click()
Dim rec As ADODB.Recordset
Set rec = New ADODB.Recordset
rec.CursorLocation = adUseClient
rec.Open "SELECT * FROM Tbl", CurrentProject.Connection, adOpenStatic,
adLockBatchOptimistic
Set rec.ActiveConnection = Nothing
rec.AddNew
rec!Text = "neu"
rec.Update
rec.ActiveConnection = CurrentProject.Connection
rec.UpdateBatch
End Sub
Oli
.
Olaf Rabbachin
> > Ich könnte zwar eine temporäre Tabelle erstellen und den User dort die
> Daten
> > eingeben lassen. Ich bin mir aber nicht sicher, ob dies wirklich die
> > sauberste Lösung ist.
>
> würd ich vermeiden wegen dem lagerhauseffekt
Was versteht man denn unter 'Lagerhauseffekt'?
Ich jedenfalls verwende temporäre Tabellen z.B. für Formulare mit
Unterformularen (oder Formulare mit in z.B. Listenfeldern dargestellten
Daten aus anderen Tabellen), die über einen 'Abbruch'-Knopf verfügen sollen,
um die geänderten Daten nötigenfalls wieder zurückzuschreiben. Das für die
Dauer der Bearbeitung zusätzlicher Speicherbedarf notwendig ist, nehme ich
dafür in Kauf - vor allem, da die Tabelle immer nur den Kerndatensatz pro
Formular/Unterformular enthält.
(Ähnlich zu "Q149358 - ACC2: Sample to Undo Changes in Forms Available in
Download Center" aus der MS-KB, bzw. bei mir eine recordset-Adaption.)
Bis dann,
Olaf
Peter Steimann
"Olaf Rabbachin" <Olaf.Ra...@t-online.de> schrieb im Newsbeitrag
news:8qnd8u$k6m$17$1...@news.t-online.com...
> Hi Peter,
>
> > > Ich könnte zwar eine temporäre Tabelle erstellen und den User dort die
> > Daten
> > > eingeben lassen. Ich bin mir aber nicht sicher, ob dies wirklich die
> > > sauberste Lösung ist.
> >
> > würd ich vermeiden wegen dem lagerhauseffekt
>
> Was versteht man denn unter 'Lagerhauseffekt'?
das aufblähen der datenbank (wie das fragmentieren einer festplatte, wobei
dort die dateien wenigstens nicht wachsen-;)
> Ich jedenfalls verwende temporäre Tabellen z.B. für Formulare mit
> Unterformularen (oder Formulare mit in z.B. Listenfeldern dargestellten
> Daten aus anderen Tabellen), die über einen 'Abbruch'-Knopf verfügen
sollen,
> um die geänderten Daten nötigenfalls wieder zurückzuschreiben.
das geht mit oldvalue doch komfortabler, oder?? das problem ist nur, wenn
mehrere datensätze gesammelt fortgeschrieben werden sollen. da kommst du
dann mit oldvalue nicht weiter
> Das für die
> Dauer der Bearbeitung zusätzlicher Speicherbedarf notwendig ist,
jeden tag ein paar 100kb mehr bis zur nächsten komprimierung??
> nehme ich
> dafür in Kauf - vor allem, da die Tabelle immer nur den Kerndatensatz pro
> Formular/Unterformular enthält.
würd ich nicht. s.o.
gruss
peter
Frederic Luchting
geht natürlich nicht.
Ich träumte, man könne recordsets als recordsources angeben.
Oli
.
"Frederic Luchting" schrieb im Traum
: Hallo Jens,
:
: : ich möchte ein Endlosformular so programmieren, daß der User darin
: Daten
: : eintragen kann. Erst wenn das Formular geschlossen wird, soll der
: User
: : gefragt werden, ob er die Daten speichern möchte. Es sollen also
: erst hier
: : die Datensätze in die eigendliche Tabelle schreiben.
: :...
: : Gibt es eine Möglichkeit, die Tabelle nur im Ram zu erstellen und
: dort mein
: : Endlosformular drauf basieren zu lassen?
:
: Ich weiß nicht ob das Deine Wünsche befriedigt aber es ist sicher
:
:
Norbert Moendjen
>>>> Ich könnte zwar eine temporäre Tabelle erstellen und den User dort die
>>> Daten
>>>> eingeben lassen. Ich bin mir aber nicht sicher, ob dies wirklich die
>>>> sauberste Lösung ist.
>>> würd ich vermeiden wegen dem lagerhauseffekt
>> Was versteht man denn unter 'Lagerhauseffekt'?
> das aufblähen der datenbank (wie das fragmentieren einer festplatte, wobei
> dort die dateien wenigstens nicht wachsen-;)
>> Ich jedenfalls verwende temporäre Tabellen z.B. für Formulare mit
>> Unterformularen (oder Formulare mit in z.B. Listenfeldern dargestellten
>> Daten aus anderen Tabellen), die über einen 'Abbruch'-Knopf verfügen
> sollen,
>> um die geänderten Daten nötigenfalls wieder zurückzuschreiben.
Wie wäre es mit einer Tabelle in die ich die Datensätze schreibe ganz
wie normal, bei drücken des Speicher-Buttons werden die Daten an
die eigentliche Tabelle angefügt. Die temporäre Tabelle wird aber nicht
gelöscht sondern nur die Inhalte mit Null überschrieben, dadurch müßte
sich mit der Zeit eine bestimmte Größe der temp. Tabelle einstellen und
der Lagerhauseffekt sollte nicht auftreten.
--
Ciao Nobbe
http://www.moendjen.de
Jens Tönsing
OPqWDKw...@cppssbbsa02.microsoft.com...
> Tschuldigung -
> geht natürlich nicht.
> Ich träumte, man könne recordsets als recordsources angeben.
>
> Oli
> .
Schade, hab mich schon gefreut....
>
>
> "Frederic Luchting" schrieb im Traum
> : Hallo Jens,
> :
> : : ich möchte ein Endlosformular so programmieren, daß der User darin
> : Daten
> : : eintragen kann. Erst wenn das Formular geschlossen wird, soll der
> : User
> : : gefragt werden, ob er die Daten speichern möchte. Es sollen also
> : erst hier
> : : die Datensätze in die eigendliche Tabelle schreiben.
> : :...
> : : Gibt es eine Möglichkeit, die Tabelle nur im Ram zu erstellen und
> : dort mein
> : : Endlosformular drauf basieren zu lassen?
Jens Tönsing
Peter Steimann <PSte...@Pilatusnet.ch> schrieb in im Newsbeitrag:
e5AS1tvJAHA.278@cppssbbsa05...
> hallo olaf
>
> "Olaf Rabbachin" <Olaf.Ra...@t-online.de> schrieb im Newsbeitrag
> news:8qnd8u$k6m$17$1...@news.t-online.com...
> > Hi Peter,
> >
> > Unterformularen (oder Formulare mit in z.B. Listenfeldern dargestellten
> > Daten aus anderen Tabellen), die über einen 'Abbruch'-Knopf verfügen
> sollen,
> > um die geänderten Daten nötigenfalls wieder zurückzuschreiben.
>
> mehrere datensätze gesammelt fortgeschrieben werden sollen. da kommst du
> dann mit oldvalue nicht weiter
>
Genau das Problem habe ich. Wie ich ganz oben geschrieben habe handelt es
sich um ein Endlosformular. Der Nutzer muß dort seine Änderungen machen
können und diese hinterher komplett verwerfen können. Also alle Datensätze
die er angelegt oder geändert hat.
Ich denke, mir bleibt nichts übrig, als die Daten in eine temporäre Tabelle
zu schreiben, dort die Änderungen vom Nutzer machen zu lassen und wenn der
Benutzer fertig ist die Daten, wenn gewünscht, zurückzuschreiben.
> > Das für die
> > Dauer der Bearbeitung zusätzlicher Speicherbedarf notwendig ist,
>
> jeden tag ein paar 100kb mehr bis zur nächsten komprimierung??
>
> > nehme ich
> > dafür in Kauf
> würd ich nicht. s.o.
Ich werde es auch in Kauf nehmen müssen. Die MDB mit den temporären Daten
werden warscheinlich programmgesteuert bei jedem Programmstart oder -ende
komprimieren.
Gegen die Fragmentierung der Festplatte wird man wohl nichts machen können.
Ich sehe diesen Nachteil aber nicht als gravierend an.
Jens
>
> gruss
>
> peter
>
Frederic Luchting
Hallo Jens,
: Schade, hab mich schon gefreut....
dann kommt noch ein kleiner Vorschlag zur
Wiedergutmachung:
Anstelle der tmp-Tabelle kann man auch
ein 'Vorläufig'-Ja/Nein Feld in der Ziel-Tabelle
verwenden.
Bei Übernahme werden die Werte einfach
geändert (erspart das Kopieren der Datensätze) -
bei Verwerfung werden alle Datensätze mit
diesem Flag gelöscht.
Der Lagerhauseffekt müsste sich so auf
verworfene Eingaben bescheiden und ist wohl
unvermeidbar.
Oli
.
Elmar Boye
"Jens Tönsing" <toen...@gmx.de> schrieb ...
> Frederic Luchting <fred...@luchting.de> schrieb ...
> > Tschuldigung -
> > geht natürlich nicht.
> > Ich träumte, man könne recordsets als recordsources angeben.
> >
> > Oli
> > .
>
> Schade, hab mich schon gefreut....
>
Tja, man kann ja schon Recordsets zuweisen in A00 via Form.Recordset.
Auch kann ADO solche Recordsets im Speicher erstellen.
Nur dummerweise verweigert Access die Aktualisierbarkeit,
wenn nicht der passende Provider dran gebunden ist bzw.
spuckt dümmliche Meldungen aus und aktualisiert lokal alles
so dass ein UpdateBatch nicht klappt.
Naja und letztens Bei MDB muss ein Recordset vom Typ DAO
sein, sonst ist es mit der Aktualiserbarkeit gleich Essig.
Ich persönlich ziehe dann doch die Temporärtabelle vor -
trotz Peters Bedenken: Im Zweifelsfall eine Arbeitsdatenbank
verwenden.
Gruss
Elmar
Peter Steimann
hallo jens
"Jens Tönsing" <toen...@gmx.de> schrieb im Newsbeitrag
news:uy$yaL4JA...@cppssbbsa02.microsoft.com...
> Peter Steimann <PSte...@Pilatusnet.ch> schrieb in im Newsbeitrag:
> e5AS1tvJAHA.278@cppssbbsa05...
> >
> > jeden tag ein paar 100kb mehr bis zur nächsten komprimierung??
> >
> > > nehme ich
> > > dafür in Kauf
> > würd ich nicht. s.o.
>
> Ich werde es auch in Kauf nehmen müssen. Die MDB mit den temporären Daten
> werden warscheinlich programmgesteuert bei jedem Programmstart oder -ende
> komprimieren.
musst du diese funktion wirklich haben?? damit die benutzer der db ihr
gehirn komplett abschalten können??
damit hab ich nicht die besten erfahrungen gemacht.
deine funktion sowie die automatische komprimierung würd ich in einem
mehrbenutzer-betrieb keinesfalls anwenden. stell dir vor, es hacken beide
auf demselben datensatz rum. natürlich kann man auch das abfangen-;)
trotzdem.
> Gegen die Fragmentierung der Festplatte wird man wohl nichts machen
können.
> Ich sehe diesen Nachteil aber nicht als gravierend an.
nee. war ja nur ein beispiel. um den lagerhaus-effekt erklären zu können.
regelmässige defragmentierung ist eh pflicht.
gruss
peter
Peter Steimann
hallo elmar
"Elmar Boye" <eb...@my-deja.com> schrieb im Newsbeitrag
news:8qpp07$gb336$2...@ID-28695.news.cis.dfn.de...
> Hallo Jens,
>
> Ich persönlich ziehe dann doch die Temporärtabelle vor -
> trotz Peters Bedenken: Im Zweifelsfall eine Arbeitsdatenbank
> verwenden.
wie schon oben angemerkt, würd ich mir aufgrund der möglichen konsequenzen
überlegen, diesen "komfort" gar nicht zur verfügung zu stellen.
dafür lieber eine stabile datenbank-;) ich hab da meine befürchtungen. wie
war das schon wieder:
"ich hab eine datenbank, welche über monate stabil gelaufen ist,......."
gruss
peter
Jens Tönsing
Peter Steimann <PSte...@Pilatusnet.ch> schrieb in im Newsbeitrag:
OBTmIZ6JAHA.246@cppssbbsa04...
> hallo jens
>
> "Jens Tönsing" <toen...@gmx.de> schrieb im Newsbeitrag
> news:uy$yaL4JA...@cppssbbsa02.microsoft.com...
> > Peter Steimann <PSte...@Pilatusnet.ch> schrieb in im Newsbeitrag:
> > e5AS1tvJAHA.278@cppssbbsa05...
> > >
> > > jeden tag ein paar 100kb mehr bis zur nächsten komprimierung??
> > >
> > > > nehme ich
> > > > dafür in Kauf
> > > würd ich nicht. s.o.
> >
> > Ich werde es auch in Kauf nehmen müssen. Die MDB mit den temporären
Daten
> > werden warscheinlich programmgesteuert bei jedem Programmstart
oder -ende
> > komprimieren.
>
> musst du diese funktion wirklich haben?? damit die benutzer der db ihr
> gehirn komplett abschalten können??
Ich gehe davon aus, daß die Benutzer des Prgs. die Ehepartner vom Chef von
kleinen Handwerkbetrieben sein werden. Dort ist es sehr oft so, daß die
Ehefrau die Büroarbeit macht.
Ich will nichts gegen Frauen sagen - Nicht daß ich hier gleich geschlachtet
werde. Aber ich muß wirklich davon ausgehen, daß die Benutzer keine Profis
sind, die die Arbeit am PC richtig gelernt haben.
>
> damit hab ich nicht die besten erfahrungen gemacht.
>
> deine funktion sowie die automatische komprimierung würd ich in einem
> mehrbenutzer-betrieb keinesfalls anwenden. stell dir vor, es hacken beide
> auf demselben datensatz rum. natürlich kann man auch das abfangen-;)
> trotzdem.
>
Ich werden die MDB mit den temporären Daten auf jeden Client legen, so daß
jeder seine eigene Temp-MDB hat. Die kann er dann nach herzenslust
komprimieren, ohne das die anderen Benutzer etwas davon mitkriegen.
Klaus Oberdalhoff
Hi,
> Ich denke, mir bleibt nichts übrig, als die Daten in eine temporäre
Tabelle
> zu schreiben, dort die Änderungen vom Nutzer machen zu lassen und wenn
[...]
mit dem im Anhang angegebenen Modul kann man nicht nur Temptables erstellen,
sondern erstellt diese in einer separaten MDB. Diese kann man dann tutto
kompletto löschen ...
--
mfg
Klaus KO...@gmx.de
Ich beantworte keine Fragen via eMail
PS:Tips und Tricks zu ACCESS 97 (** KnowHow-MDB ** Ver 3.0 - 30.9.1999)
unter http://www.accessware.de/
Access-FAQ bei: http://www.donkarl.com/AccessFAQ.htm
Sub TempTablesSample()
' This subroutine illustrates how to use a temporary MDB in your app.
' If the temporary MDB is present then delete it.
' The name of the temporary MDB created is the same as the current Front
End (FE) name with
' " temp" added to the end of the name.
' Create the temporary MDB.
' Create the temporary table(s) required in the temporary MDB.
' Link to those tables within your current FE
' Do whatever you want
' Unlink the tables'
' Delete the temporary MDB
' While this code is copyright 2000 by Tony Toews it's all code strung
together from the online help so do
' whatever you like with this. At your own risk.
Dim tdfNew As TableDef, RS As Recordset
Dim wrkDefault As Workspace
Dim dbsTemp As Database, strTempDatabase As String
Dim strTableName As String
' Get default Workspace.
Set wrkDefault = DBEngine.Workspaces(0)
strTempDatabase = Left$(CurrentDb.Name, Len(CurrentDb.Name) - 4) & "
temp.mdb"
' Make sure there isn't already a file with the name of
' the new database.
If Dir(strTempDatabase) <> "" Then Kill strTempDatabase
'Create a new temp database
Set dbsTemp = wrkDefault.CreateDatabase(strTempDatabase, dbLangGeneral)
strTableName = "temp Import Materials"
'strBracketedTableName = "[" & strTableName & "]"
' Delete the link to the temp table if it exists
If TableExists(strTableName) Then
CurrentDb.TableDefs.Delete strTableName
End If
' Create the temp table
Set tdfNew = dbsTemp.CreateTableDef(strTableName)
With tdfNew
.Fields.Append .CreateField("Invoice", dbLong)
.Fields.Append .CreateField("InvoiceItemNumber", dbInteger)
.Fields.Append .CreateField("InvoiceMaterialCode", dbText)
.Fields.Append .CreateField("Line2", dbText)
.Fields.Append .CreateField("Line3", dbText)
.Fields.Append .CreateField("LengthOrQuantity", dbDouble)
dbsTemp.TableDefs.Append tdfNew
End With
dbsTemp.TableDefs.Refresh
Dim tdfLinked As TableDef
' Link to the Import tables in the temp MDB
Set tdfLinked = CurrentDb.CreateTableDef(strTableName)
tdfLinked.Connect = ";DATABASE=" & strTempDatabase
tdfLinked.SourceTableName = strTableName
CurrentDb.TableDefs.Append tdfLinked
CurrentDb.TableDefs.Refresh
RefreshDatabaseWindow
Set RS = CurrentDb.OpenRecordset(strTableName, dbOpenDynaset,
dbAppendOnly)
' Do your logic to the temp tables here.
RS.Close
dbsTemp.Close
CurrentDb.TableDefs.Refresh
Set RS = Nothing
Set dbsTemp = Nothing
' Unlink the tables
CurrentDb.TableDefs.Delete strTableName
' Delete the temp mdb
strTempDatabase = Left$(CurrentDb.Name, Len(CurrentDb.Name) - 4) & "
temp.mdb"
Kill (strTempDatabase)
tagExit:
Exit Sub
tagError:
DoCmd.Hourglass False
If Err.Number = 70 Then
MsgBox "Unable to delete temporary database as it is locked." &
vbCrLf & vbCrLf & _
"Import cancelled."
Else
MsgBox Err.Description, vbCritical
End If
End Sub
Function TableExists(strTableName As String) As Integer
' Checks for the existance of a specific table
'Added the tabledefs.refresh as tables just added in this session
weren't
' being picked up.
Dim dbDatabase As Database, tdefTable As TableDef
On Error Resume Next
Set dbDatabase = DBEngine(0)(0)
dbDatabase.TableDefs.Refresh
Set tdefTable = dbDatabase(strTableName)
' If an error occurred the tabledef object could not be accessed and
' therefore doesn't exist. This could cause problems in a secured
environment
' though as access may be denied.
If Err = 0 Then
TableExists = True
Else
TableExists = False
End If
End Function
Peter Steimann
"Jens Tönsing" <toen...@gmx.de> schrieb im Newsbeitrag
news:OZgLDp6...@cppssbbsa02.microsoft.com...
>
>
> Ich gehe davon aus, daß die Benutzer des Prgs. die Ehepartner vom Chef von
> kleinen Handwerkbetrieben sein werden. Dort ist es sehr oft so, daß die
> Ehefrau die Büroarbeit macht.
> Ich will nichts gegen Frauen sagen - Nicht daß ich hier gleich
geschlachtet
> werde. Aber ich muß wirklich davon ausgehen, daß die Benutzer keine Profis
> sind, die die Arbeit am PC richtig gelernt haben.
profis sein müssen sie auch nicht. nur exakt arbeiten, wie sie das sonst
auch tun sollten. (wie z.b. beim ausfüllen der steuererklärung, da wird's
mit tipp-ex auch schon schwierig-;)
>
> >
> > damit hab ich nicht die besten erfahrungen gemacht.
> >
> > deine funktion sowie die automatische komprimierung würd ich in einem
> > mehrbenutzer-betrieb keinesfalls anwenden. stell dir vor, es hacken
beide
> > auf demselben datensatz rum. natürlich kann man auch das abfangen-;)
> > trotzdem.
> >
>
> Ich werden die MDB mit den temporären Daten auf jeden Client legen, so daß
> jeder seine eigene Temp-MDB hat. Die kann er dann nach herzenslust
> komprimieren, ohne das die anderen Benutzer etwas davon mitkriegen.
>
oder noch besser: leg die temporären tabellen in einer eigenen mdb ab.
gruss
peter
Olaf Rabbachin
> deine funktion sowie die automatische komprimierung würd ich in einem
> mehrbenutzer-betrieb keinesfalls anwenden. stell dir vor, es hacken beide
> auf demselben datensatz rum. natürlich kann man auch das abfangen-;)
> trotzdem.
> [...]
> nee. war ja nur ein beispiel. um den lagerhaus-effekt erklären zu können.
> regelmässige defragmentierung ist eh pflicht.
Ist irgendwie widersprüchlich - Komprimieren nein danke, aber
defragmentieren doch?
Schließlich setzt die Defragmentierung mehr als alles andere voraus, daß
Ruhe auf dem Server/Rechner herrscht. Was spricht gegen ein Komprimieren
während der Ruhezeiten? Und wenn's diese nicht gibt, wird halt auch für's
Defragmentieren in gewissen Abständen zwangsweise das System nicht verfügbar
sein.
Bis dann,
Olaf
Elmar Boye
"Peter Steimann" <PSte...@Pilatusnet.ch> schrieb ...
>
> hallo elmar
>
> "Elmar Boye" <eb...@my-deja.com> schrieb ...
> > Hallo Jens,
> >
> > Ich persönlich ziehe dann doch die Temporärtabelle vor -
> > trotz Peters Bedenken: Im Zweifelsfall eine Arbeitsdatenbank
> > verwenden.
>
> wie schon oben angemerkt, würd ich mir aufgrund der möglichen konsequenzen
> überlegen, diesen "komfort" gar nicht zur verfügung zu stellen.
>
> dafür lieber eine stabile datenbank-;) ich hab da meine befürchtungen. wie
> war das schon wieder:
>
> "ich hab eine datenbank, welche über monate stabil gelaufen ist,......."
>
> gruss
>
> peter
>
logischerweise muss man schon gucken, ob das Ganze denn auch stabil läuft.
Mal gerade reinhängen und es wird schon laufen, ist denn doch etwas
blauäugig.
Und als Standardprogrammiertechnik eignet es sich im Multi-User-Betrieb
ohnehin nicht: Wenn man konkurrierende Zugriffe sauber regeln will,
treibt es einen schnell den Schweiss auf die Stirn.
Ein UpdateBatch wie es z. B. Frederic da gerade mal fix hingeschrieben
hat, klappt ja oft aber eben nur in 99,8 Prozent und die 0,2 Prozent
machen dann schnell 99,999 Prozent der Programmierei aus.
Was lob ich mir dann: "Der Datensatz wurde von einem anderen Anwender
geändert..." - das kann dem "doofen Access" in die Schuhe schieben ;-)
Aber spätestens wenn Du etwas mehr im Client/Server Umfeld bastelst
wirst Du feststellen, dass eine lokale Tabelle doch so manchen
Verkehr auf der Leitung spart.
Was im übrigen auch für Access mit Backend auf dem Server gilt.
Ich habe eine ziemlich dicke Access Anwendung, die sich gerade
dadurch auf Socken macht.
Und was die Arbeit-Datenbank angeht sind wir uns ja anscheinend
ohnehin einig.
Gruss
Elmar
Peter Steimann
hallo olaf
"Olaf Rabbachin" <Olaf.Ra...@t-online.de> schrieb im Newsbeitrag
news:8qqh7r$7ov$10$1...@news.t-online.com...
> Hi Peter,
>
> > deine funktion sowie die automatische komprimierung würd ich in einem
> > mehrbenutzer-betrieb keinesfalls anwenden. stell dir vor, es hacken
beide
> > auf demselben datensatz rum. natürlich kann man auch das abfangen-;)
> > trotzdem.
> > [...]
> > nee. war ja nur ein beispiel. um den lagerhaus-effekt erklären zu
können.
> > regelmässige defragmentierung ist eh pflicht.
>
> Ist irgendwie widersprüchlich - Komprimieren nein danke, aber
> defragmentieren doch?
hab ich nicht behauptet. das bezog sich auf die option in a2000, wo du die
komprimierung automatisch beim schliessen durchführen lassen kannst. die
datenbanken kannst du nie genug komprimieren-;)
>
> Schließlich setzt die Defragmentierung mehr als alles andere voraus, daß
> Ruhe auf dem Server/Rechner herrscht. Was spricht gegen ein Komprimieren
> während der Ruhezeiten?
ganz und gar nichts!! wieviel's auf einem server bringt, ist eine andere
frage. aber schaden kann's nicht.
> Und wenn's diese nicht gibt, wird halt auch für's
> Defragmentieren in gewissen Abständen zwangsweise das System nicht
verfügbar
> sein.
ntfs fragmentiert ned so stark wie fat oder fat32. schden tut's sicher
nicht. ich seh aber keine notwedigkeit, einen fileserver täglich zu
defragmentieren.
meine arbeitsstation hier defragmentier ich fast täglich, die
entwicklungs-db's werden sowieso täglich gesichert und komprimiert. und
mein server ist ein linux, da brauch ich gar nix zu defragmentieren-;)
gruss
peter
Jens Tönsing
Peter Steimann <PSte...@Pilatusnet.ch> schrieb in im Newsbeitrag:
> >
> > Ich werden die MDB mit den temporären Daten auf jeden Client legen, so
daß
> > jeder seine eigene Temp-MDB hat. Die kann er dann nach herzenslust
> > komprimieren, ohne das die anderen Benutzer etwas davon mitkriegen.
> >
>
> oder noch besser: leg die temporären tabellen in einer eigenen mdb ab.
>
Genau das meinte ich.
Jens
Gerhard Amberger
BeginTrans-, CommitTrans-, Rollback-Methoden
Folgendes sollten sich verschiedene Beteiligte dieses Threads zu
Gemuete fuehren:
http://learn.to/quote
Danke.
Gerhard Amberger
Ralf Mueller
Jens Tnsing <toen...@gmx.de> schrieb am 26.09.00
^^^^^^
So sehen können übrigens Umlaute im Realnamen aussehen ...
zum Thema: Re: Recordset nur in RAM erstellen / A00
> > Ich träumte, man könne recordsets als recordsources angeben.
> Schade, hab mich schon gefreut....
Wie wäre es denn, wenn Du jeden Datensatz, den Du bearbeiten möchtest,
vor der Bearbeitung erst in eine Object-Variable einliest und die
geänderten Daten erstmal normal im Formular speicherst. Das 'richtige'
Eingeben von Änderungen sollte eigentlich auch der Normalfall der
Bedienung sein. Falls nun doch die Änderungen widerrufen werden sollen,
kannst Du die 'alten' Daten aus der Variable wieder einlesen,
andernfalls setzt Du die Variable zurück.
Ich verwende diese Methode, da meine Bedienungsbuttons (Bearbeiten,
Speichern, Abbrechen, ...) auf dem HFO liegen, die Daten aber in einem
UFO eingegeben werden; klicke ich auf den ABBRECHEN-Button (im HFO),
d.h. verlasse ich das UFO speichert ACCESS ja automatisch meine Daten.
Deshalb muß ich dann durch obigen Kniff die alten Daten aus der Variable
wiederherstellen.
Klappt hier mit ACC97 eigentlich problemlos; d.h. ein kleines Problem
gibt es mit MEMO's: diese werden bei:
Dim aktuellerDatensatz as Object
set aktuellerDatensatz =
aktuellesUFO.RecordsetClone.OpenRecordset(dbOpenSnapshot, dbReadOnly)
nicht als Inhalt, sondern aus Performancegründen als Verweis übergeben
(it's not a bug - it's a feature).
Dadurch wirken sich jegliche Änderungen sofort auch auf den in der
Variable abgebildeten MEMO-Feld-Inhalt aus und Du hast dort immer den
aktuellen Wert und kommst an den alten nicht mehr ran. Aber auch da kann
man drum herum programmieren.
Gruß
Ralf