Eine temporäre Tabelle für jeden User?

[Luckner]

Hallo,
schreibe ein spezielles Artikel- und Rechnungsprogramm für unsere Firma. Habe eine Datenbank mit den Stamm-Tabellen erstellt. Mache mich jetzt ran an die Angebote usw. Meine Idee ist, eine temporäre Tabelle zu erstellen, in der die z.B. gesammelten Artikel für aktl. Angebot eingetragen sind, evtl. mit kleinen Änderungen, um sie dann in einer zentralen Datenbank mit einer Angebotsnummer zu speichern. Diese temp. Tabellen müßte man, so denke ich, für jeden User erstellen. Gibt es, irgendwelche Komponenten, die so eine Tabelle im Speicher halten könnten? Ich könnte es auch mit einer lokalen Tabelle versuchen, aus der ich beim speichern, den Inhalt des Angebotes, in die zentrale Datenbank kopiere und dann den Inhalt der temp. Tabelle lösche. Ich hoffe, ich habe meine Gedanken einigermassen plausibel beschrieben.

Gruß, Luckner

[Luckner]

Habe, gerade, in Lazarus die Komponente "TBufDataset" gefunden. Ob sie für diesen Zweck hilfreich wäre?

Luckner

[af0815]

Wie persistent muss die lokale Tabelle (Datenbank) sein ? Muss sie die Laufzeit des Programmes übersteigen ? Was ist wenn der User in die Mittagspause geht und nachher was wichtigers vom Chef machen muss und das Programm einfach schliesst ?

[Luckner]

Hallo af0815,
wenn der User in die Mittagspaue, bzw. Telefon usw. ist, dann sollte die Tabelle noch vorhanden sein. Bis der User im Programm Button-Speichern klickt, dann werden, als Beispiel alle Artikel aus der temp. Tabelle in die zentrale Datenbank, mit dem Eintrag der erzeugten Angebotsnummer, übernommen. Falls Button-Abbrechen oder Programmabbruch dann wird Nichts übernommen und temp. Tabelle gelöscht. Ich würde den Inhalt der temp. Tabelle bei neuem Angebot löschen.

Gruß, Luckner

[af0815]

Dann kannst du lokal gleich mal ein persistentes System vorhalten. Also so was was die Daten echt lokal zwischenspeichert und nicht nur im Memory.
Da gibt es verschiedene Varianten. Je nachdem wie kompliziert es lokal wird und was du installieren lassen willst.

Eine Suche im Forum lohnt sich allemal. Zum Beispiel viewtopic.php?f=18&t=13604

[Soner]

Ich mache in meinem Programm das was du vorhast.
Ich benutze ZEOS-Komponenten und benutze die Eigenschaft CachedUpdates von TZQuery.
Die Benutzer können alles eingeben, erst wenn sie die Daten an die DB-Senden (speichern klicken) werden die Daten mit Primärschlüssel versorgt.
Da braucht man keine temporäre Tabelle. Natürlich wenn die Benutzer das Programm beenden, dann wird alle Eingaben verworfen, falls die Benutzer es nicht speichern möchten.

Ich konnte keine "CachedUpdate"-Eigenschaft bei SQLdb-Komponenten finden, ich habe diese Komponenten nie richtig benutzt, deshalb kenne ich mich damit nicht aus. Vielleicht gibt es hier SQLdb experten.

Welche Datenbankkomponenten und Datenbanksystem benutzt du?

Edit: Ich habe nachgeschaut, TSqlQuery soll auch CachedUpdates benutzen. Gut zu wissen, ich überlege in der neuen Version zu SQLDB zu wechseln.

[af0815]

Edit: Ich habe nachgeschaut, TSqlQuery soll auch CachedUpdates benutzen. Gut zu wissen, ich überlege in der neuen Version zu SQLDB zu wechseln.

Ich glaube nicht das es dasselbe ist. Es ist eigentlich ein alter Hut, deswegen muss man ApplyUpdates für Änderungen nachschießen. Aber ich kenne das auch anders, so das man die Datenquelle echt zwischendurch trennen kann, das geht bei SQLDb nicht. Zumindest nicht bei mir.

Und besonders persistent ist das auch nicht. Programm schließen (oder Crash) und weg ist alles (auch bei Zeos). Aber Ok, das ist eine Designentscheidung.

[Soner]

@af0815
Soweit ich Luckner verstanden habe, möchte er nicht Programm schließen.
Deine Lösung ist gut aber wozu unnötige Arbeit wenn es nicht gebraucht wird. Ich glaube hier reicht "CachedUpdate".

@Luckner
Ich habe nochmal angeschaut, falls du TSQLQuery und automatische Primärschlüssel(Index) verwendest, dann musst du wahrschlich TSQL.Sequence.AplyEvent den Wert "saeOnPost" vergeben. Sonst würde das System unnötig Primärschlüssel vergeuden, falls die Benutzer die Daten nicht Speichern.
Ich mache es manuell aber ich denke das hier ist sogar besser, falls es das tut was ich vermute.

[af0815]

@af0815
Soweit ich Luckner verstanden habe, möchte er nicht Programm schließen.
Deine Lösung ist gut aber wozu unnötige Arbeit wenn es nicht gebraucht wird. Ich glaube hier reicht "CachedUpdate".

Deswegen schrieb ich, das es eine Designentscheidung ist. Oft will der User ein Programm nicht schliessen aber es es ist trotzdem tot, wenn der Manager den Laptop aus dem Dock nimmt, die Verbindung zum Server im Ar... ist und er dann im Meetingroom feststellt, das das Programm die verloren hat, weil die Verbindung weg war. Klar ist es DEIN Programm das das Problem hat, nicht sein Umgang mit dem Laptop Programm. Und auch von einem Vorgang abschließen oder Logout will der nichts wissen, das hat das Programm zu erledigen, er ist ja Manager und kein IT-Experte.
(Meine Designentscheidung war dann im 2ten Anlauf, das ganze auf einem Webserver zu legen)

Nochmals, deswegen vorher mal überlegen was sinnvoller ist. Lokal wirkl vorhalten oder sich auf ChachedUpdate zu verlassen. Alles hat VT und NT

[Luckner]

Danke für die Anregungen,
ich denke ich mache es mit einer localen Tabelle pro User. Wenn der Rechner mal vom Strom fliegt, oder sonstwie abschmiert, dann sind eben die localen Daten noch vorhanden. Aber das Handling mit mehreren Usern wird so einfacher. Diese Tabelle wird bei jedem User in einem festen Unterverzeichnis angelegt und nach jedem speichern dann geleert.

Gruß, Luckner

[Soner]

Danke für die Anregungen,
ich denke ich mache es mit einer localen Tabelle pro User. Wenn der Rechner mal vom Strom fliegt, oder sonstwie abschmiert, dann sind eben die localen Daten noch vorhanden. Aber das Handling mit mehreren Usern wird so einfacher. Diese Tabelle wird bei jedem User in einem festen Unterverzeichnis angelegt und nach jedem speichern dann geleert.

Gruß, Luckner

Wenn du temporäre Tabellen verwendest, dann würde ich die temporären Dateien zentral bei der Datenbank in einer Tabelle als BLOB-Feld Speichern. Wenn jemand den Arbeitsplatz/Computer wechselt, dann kann er einfach weiterarbeiten. Aus diesem Grunde, habe ich die Einstellungsdateien ("Ini-Dateiein") in den Datenbank-Server verlegt. Lokal ist bei mir nur die Serveradresse hinterlegt.

[charlytango]

Meine Idee ist, eine temporäre Tabelle zu erstellen, in der die z.B. gesammelten Artikel für aktl. Angebot eingetragen sind, evtl. mit kleinen Änderungen, um sie dann in einer

Aus meiner Sicht ist das alles viel zu kompliziert. Irgendwas hin und her kopieren, vorhalten, cachen.

Angebote, Aufträge, Rechnungen etc etc können in meinem Design immer und jederzeit direkt in der Datenbank erstellt und geändert werden, denn sie sind erstmal "Vorschläge".
Ein "Dokument" ist solange als "in Arbeit" gekennzeichnet bis es freigegeben wird.

Von Sachbearbeitern erwarte ich dass sie einen "Speichern-Knopf" drücken können, wenn sie "Zwischen"-Speichern wollen. Dann wird die geöffnete Transaktion commited und die Daten in die DB geschrieben. Das in erster Linie deswegen weil meistens eine "Abbrechen" Funktion gewünscht wird.

Die Freigabe erfolgt mit einem eigenen Button der nur einmal benutzt werden kann. Dann speichere ich auch User und Freigabetimestamp.

Ab diesem Zeitpunkt ist es ein echter Beleg der im Geschäftsprozess nicht mehr änderbar ist. (nur durch eine explizite Änderungsbuchung - also ein neues Dokument -- oder durch Eingriff eines Admins der weiß was er tut gggg)

So eng muss man es nicht sehen, man kann auch vor einem erneuten Änderungswunsch nachsehen ob der "Auftrag" bereits irgend eine Art von Weiterverarbeitung (ZB für einen Lieferschein oder eine Rechnung) erfahren hat und dann doch das Ändern erlauben -- aber das ist Designentscheidung und vor allem vom Business-Case abhängig.

just my 2 cents

[Luckner]

Hallo charlytango,
jetzt bin ich soweit, dass ich Das, was ich davor geschrieben habe umsetzen will. Wie machst Du das, wenn 2 und mehr Anwender gleichzeitig ein neues Dokument(Angebot, Auftrag usw.) anlegen? Erstellt das Programm für jeden User neue Tabellen? Was passiert, wenn ein User diese Dokumenterstellung dann abbrechen möchte (aus welchen Gründen auch immer), werden die Datensätze irgendwie gelöscht? Woher weiß die Anwendung, welche Datensätze, zu welchen Usern gehören?

Für eine temp. locale Datenbank spricht doch dafür, dass ich die komplette Datenbank leeren kann, wenn der Anwender oder Computer abbricht. Problem habe ich nur, dass ich local auch eine FB-Server Version installieren muß. Obwohl local könnte auch eine Embeddet-Version funktionieren.

Gruß, Andreas

[charlytango]

Hallo charlytango,
jetzt bin ich soweit, dass ich Das, was ich davor geschrieben habe umsetzen will. Wie machst Du das, wenn 2 und mehr Anwender gleichzeitig ein neues Dokument(Angebot, Auftrag usw.) anlegen? Erstellt das Programm für jeden User neue Tabellen? Was passiert, wenn ein User diese Dokumenterstellung dann abbrechen möchte (aus welchen Gründen auch immer), werden die Datensätze irgendwie gelöscht? Woher weiß die Anwendung, welche Datensätze, zu welchen Usern gehören?

Für eine temp. locale Datenbank spricht doch dafür, dass ich die komplette Datenbank leeren kann, wenn der Anwender oder Computer abbricht. Problem habe ich nur, dass ich local auch eine FB-Server Version installieren muß. Obwohl local könnte auch eine Embeddet-Version funktionieren.

Gruß, Andreas

Ich denke da brauchts erst eine Definition von Begrifflichkeiten.
Es gibt bei einer DB-Applikation kein (physisches) "Dokument".
Ein Auftrag ist ZB eine Sammlung von Daten über verschiedene Tabellen.

Für eine Mehrbenutzerumgebung sind mehrere Designentscheidungen nötig -- eine davon ist die Frage ob mehrere Benutzer gleichzeitig an einem Aufrag arbeiten sollen/dürfen.
Bisher habe ich das in diversen Applikationen so gelöst dass ein User den Auftrag, den er gerade bearbeitet "sperrt" -- ein anderer User kann gleichzeitig in diesem Auftrag nichts bearbeiten. Jeder Benutzer kann aber beliebig viele Aufträge gleichzeitig bearbeiten die nicht von anderen Usern gesperrt wurden.

Die Tabelle TAuftrag sieht in etwa so aus:
AUFTRID (Prim Key der Tabelle)
Auftragsnummer (eine Auftragsnummer die nach Kundenwunsch gebaut wird)
KundenID (ID des Kunden zu dem der Auftrag gehört)
--Rechnungsadresse
--Lieferadresse
Auftragsdatum
etc etc.
Dazu Daten wie ErstellerID (Wer erstellt den Auftrag und wann)
Auftragsfreigabe von/am/um

eine n:m Tabelle speichert die zugeordneten Artikel
AUFTARTID (Primary key der Tabelle - nicht immer nötig aber für Datenkomponenten nützlich)
AUFTRID
ArtikelID
Artikelpreis (diverse Daten die sich ändern könnten werden aus der Artikeltabelle kopiert)
Rabatte etc etc.

Sobald ein Auftrag erstellt (oder geändert)wird, wird ein Datensatz in TAuftrag angelegt und gleichzeitig ein Eintrag in einer Sperrtabelle gemacht -- Auftrag für User XY gesperrt. Sperren werden erst erstellt wenn ein Auftrag tatsächlich geändert wird. Ansehen geht immer.

An einem Auftrag kann solange herumgeändert werden solange er nicht freigegeben ist. Daher erübrigt sich irgend eine lokale Zwischenspeicherung.

Die Sperre in der Sperrtabelle wird entfernt sobald der Benutzer auf "Speichern" drückt. Vorher wird mit CachedUpdates gearbeitet.

Irgendwelche lokalen Tabellen oder Temporärtabellen die pro User erstellt werden sind nicht nötig.

Diese Strategie hat sich jahrzehntelang im Mehrbenutzerbetrieb bewährt.
Sollte es zu Abstürzen kommen und Sperreinträge in der Sperrtabelle verbleiben braucht es natürlich eine Funktionalität damit zb ein Superuser im Unternehmen diese auch wieder manuell entfernen kann.

Schutz gegen gleichzeitiges Bearbeiten im Mehrbenutzerbetrieb (= meine Bezeichnung ist "Sperren") mache ich nicht auf Tabellen- oder Recordebene in der Datenbank sondern ich sperre "logische Bereiche". ZB Auftrag mit ID XY ist mit Timestamp von User Maxi gesperrt.) Und da hängen dann auch ZB die Artikelzuordnungen und andere Tabellen(teile) mit drin. Die Zugriffe regelt die GUI.

Die Strategie mit CachedUpdates ist dem Wunsch geschuldet dass die meisten Unternehmen sich einen "Abbrechen" Button wünschen um quasi eingegebenen Mist mit einer einzigen Aktion resetten zu können.
ZB sind auf einem Formular oben die Auftragsdaten einzugeben und darunter in einem Grid die Artikel zuzuordnen -- irgendwann will der user abbrechen und wünscht sich einen einzigen Button dazu. Dien Downside ist, dass eben dann auch ein gemeinsamer "Speichern" Button gedrückt werden muß um Änderungen in die DB zu schreiben.

**********************
Diese Strategie hilft aber nicht gegen Dummheit und Fehlbedienung wie af0815 ausführte.

Dann wären im Anlassfall eben die Daten weg die unser Oberguru gedankenlos ungespeichert ließ. In der Praxis hatte ein "Manager" ohnedies keine Berechtigung im System operativ etwas zu ändern.
*********************************

Soll so etwas auch abgefangen werden, hilft nur, jede atomare Änderung automatisiert sofort in die DB zu schreiben, was auch kein Thema wäre.
Ein Abbrechen Button oder ein "zurück" wäre dann allerdings schwieriger und müsste durch eine Art Protokollierung umgesetzt werden.
******************************
Aber das ginge dann alles schon sehr tief ins Applikations- und Datenbankdesign und würde vermutlich den Forumsrahmen sprengen.
All das hat aber weniger mit Lazarus als mit Applikationsdesign zu tun.

Bei tieferen Fragen gerne Per PM.

[af0815]

Bei tieferen Fragen gerne Per PM.

Ich würde es bevorzugen, wenn der Erfahrungsaustausch öffentlich ist. Auch ich kann noch von Ideen anderer partizipieren, weil im Laufe der Zeit wird der Fachidioten-Tunnelblick immer größer

Alleine der letzte Beitrag hat einiges an Infos für mich, wie man es anders auch machen kann. Ich verwende da öfters den Ansatz alles am Server zu machen, weil manches am Webserver gelandet ist und dort vieles ziemlich 'stateless' zu betrachten ist. Damit gehen die 'CachedUpdates' nur bedingt.