Allgemeines Datenbankproblem bei SQL Abfrage

[Hansa]

Zitat:

Zitat von Jens Hartmann

.. ist halt nur echt aufwendig die ganze Page zu drucken..

Dann kaufe dir das bereits gedruckte IBExpert-Book. 8) Und englisch ? Nun ja, schon blöd, wenn man das nicht lesen kann. Wer sich allerdings die Mühe macht, seine eigenen Bezeichner auf englisch zu übersetzen, der sollte auch mit den Begriffen (Table=Tabelle) (Database=Datenbank) etc. zurechtkommen. Computerenglisch lesen ist jedenfalls wesentlich einfacher, als z.B. mit Bush in Texas zu reden. :mrgreen:

[alex517]

falls du diese Daten auswerten willst ist es auf jeden Fall sinnvoll.
Die Umwandlung solltes du im Delphi-Programm machen und die Werte über

Delphi-Quellcode:

MyDataSet.ParamByName('DATUM').AsDate := ..
MyDataSet.ParamByName('UHRZEIT').AsTime := ..

setzten. Damit ist das korrekte Eintragen gewährleistet.
Zusätzlich könnte man den von Gerät für das Ereignis gelieferten String als
Original in einem VARCHAR oder Blob speichern um bei evtuellen Problemen darauf
zugreifen zu können.
alex

[Jens Hartmann]

Zitat:

Dann kaufe dir das bereits gedruckte IBExpert-Book. Und englisch ? Nun ja, schon blöd, wenn man das nicht lesen kann. Wer sich allerdings die Mühe macht, seine eigenen Bezeichner auf englisch zu übersetzen, der sollte auch mit den Begriffen (Table=Tabelle) (Database=Datenbank) etc. zurechtkommen. Computerenglisch lesen ist jedenfalls wesentlich einfacher, als z.B. mit Bush in Texas zu reden.

Ach Hansa, bist echt en netter Typ.

Weißt Du, ich habe genau aus dem Grund (weil ich davon ausgegangen bin, das man englisch verwenden sollte) z.B. USER genommen statt BENUTZER. Es ist auch nicht so, das ich Table und Database nicht übersetzt bekomme. Ich bekomme es auch hin einen ganz Text zu lesen. Es ist nur einfacher, für mich in Deutsch , weil ich halt einen Text in englisch nicht fehlerfrei und schnell lesen kann.
Außerdem, ist aller Anfang schwer, und die ganzen Informationen zu sortieren, zu verstehen und anschließende Fehlerfrei umzusetzten, ist halt nicht einfach. Und dafür, das ich das Thema nicht beruflich mache, denke ich bin ich schon echt weitgekommen.
Und wenn es da ein Buch zu IBExpert und Firebird in Deutsch gibt, bin ich auch bereit sowas zu kaufen und zu lesen.
Ich hoffe Du kannst mich wenigstens ein wenig verstehen, auch wenn wir zwei schon öfters verschiedener Ansichten waren.

Trotzdem Gruß Jens

[Jens Hartmann]

Zitat:

falls du diese Daten auswerten willst ist es auf jeden Fall sinnvoll.
Die Umwandlung solltes du im Delphi-Programm machen und die Werte über
Delphi-Quellcode: markieren
MyDataSet.ParamByName('DATUM').AsDate := ..
MyDataSet.ParamByName('UHRZEIT').AsTime := ..


setzten. Damit ist das korrekte Eintragen gewährleistet.
Zusätzlich könnte man den von Gerät für das Ereignis gelieferten String als
Original in einem VARCHAR oder Blob speichern um bei evtuellen Problemen darauf
zugreifen zu können.

Alles klar, werde ich mal angehen und versuchen umzusetzten.

Gruß Jens

[hoika]

Hallo,

noch zum Datum.
Falls die Nutzer mal eine Einschränkung wollen,
z.B. die Daten eines Monats, geht das per Extract mit einem Date
viel viel einfacher als mit einem String.


Heiko

[Jens Hartmann]

Zitat:

Falls die Nutzer mal eine Einschränkung wollen,
z.B. die Daten eines Monats, geht das per Extract mit einem Date viel viel einfacher als mit einem String.

Das ist aufjedenfall ein guter Grund, weil ich genau das benötige, und momentan den String prüfe. Funktioniert zwar, ich hatte mir aber schon gedacht, das man das besser lösen kann. Werde ich mir also umgehend anschauen.

Das sind alles so Aufgabe, die ich mir gesetzt habe, wenn ich das Programm soweit fertig habe, den Code zu optimieren, was man aber jetzt schon machen kann, sollte man auch tun. Daher werde ich mich heute direkt an Eure Vorschläge geben.

Gruß Jens

[Jens Hartmann]

Zitat:

- jede Tabelle bekommt Felder aus denen zu ersehen ist wann und von wem der
Datensatz angelegt und das letzte mal geändert wurde.

Ich denke, das ich das nur für die Systemtabellen benötige, um nachvollziehen zu können, wer und wann, was an den Einstellungen geändert worden ist. Die Ereignistabellen, werden automatisch durch Daten der COM-Schnittstelle beschrieben, und dürfen garnicht erst durch den USER geändert werden.

Zitat:

Das Eintragen diese Werte erfolgt über Before-Trigger die beim Insert und
Update gefeuert werden. Damit ist allein Firebird bzw. der Rechner aus dem Firebird
läuft für der Inhalt zuständig und nicht irgendein Client-Rechner oder das Programm.
Hilft ungemein beim Interpretieren der Daten, bei der Fehlersuche und
beim "Bewerten" von Kundenaussagen.


Beispiel:
DC, DM sind DOM_DATETIME,
UC, UM sind DOM_BENUTZER

Allerdings, habe ich das noch nicht so ganz verstanden. Wenn ich es verstanden habe, bedeutet das, über die im Beispiel erstellte Routine, wird durch die Firebird, automatisch die Zeit und der Benutzername in die jeweilige Tabelle eingetrage. Das heißt, das sind aber dann die Benutzer die gerade an der Datenbank angemeldet sind. Das heißt, da ich momentan noch mit den Standartwerten SYSDBA/masterkey arbeite, würde immer dieser eingetragen. Was dann bedeuten würde, das ich jedem Programmnutzer, auch einen Datenbankzugang einrichten müsste, der dann eingetragen werden könnte.

Im Anhang, habe ich übrigens mal die geänderte Datenbank, vieleicht kann mir ja mal jemand sagen, ob das jetzt besser aussieht.

Gruß Jens

[alex517]

Hallo Jens,

- Bevor du etwas anders macht, leg einen neuen Firebird-User an und erstelle deine Datenbank
mit diesem neuen User als Owner. Also weg von SYSDBA/masterkey.
Das wird dir Probleme beim Kunden ersparen. Und der nachträgliche Umstieg ist nicht ganz trivial.

Zitat:

Wenn ich es verstanden habe, bedeutet das, über die im Beispiel erstellte Routine, wird durch die Firebird, automatisch die Zeit und der Benutzername in die jeweilige Tabelle eingetrage. Das heißt, das sind aber dann die Benutzer die gerade an der Datenbank angemeldet sind. Das heißt, da ich momentan noch mit den Standartwerten SYSDBA/masterkey arbeite, würde immer dieser eingetragen. Was dann bedeuten würde, das ich jedem Programmnutzer, auch einen Datenbankzugang einrichten müsste, der dann eingetragen werden könnte.

Du kannst beim Connect deines Programm zur Datenbank deine selbst verwalteten Benutzernamen
in einer "Context Variable" hinterlegen. Wenn du das im Context der Session machst,
steht diese Variablen solange zur Verfügung wie die Connection besteht.
Diese Variable kannst du dann im Trigger abfragen und in das entsprechende Datenfeld eintragen.
Damit muss nicht jeder Benutzer einen eigenen Datenbankzugang haben.
Siehe auch hier.

- Für die ID solltest du so wie für alle anderen Felder eine Domäne anlegen,
die außerdem Not NULL sein sollte.

- Je nach gewünschter Auswertung wirst du später noch Indizes anlegen müssen um die
Abfragen entsprechend performant zu gestallten.

alex

[Jens Hartmann]

Hallo Alex,

werde jetzt erstmal diese Sachen versuchen umzusetzen.

alex hat geschrieben:

Zitat:

- Für die ID solltest du so wie für alle anderen Felder eine Domäne anlegen,
die außerdem Not NULL sein sollte.

[FRAGE]wie bekommt man eigendlich das 'alex hat geschrieben' an die Stelle von Zitat:[FRAGE ENDE]

Für das Feld ID hatte ich eine Domäne angelegt, konnte diese allerdings, nicht ändern, da das Feld der Primärschlüssel ist, und IBExpert kein Commit zugelassen hat.

Danke für die freundliche Hilfe

Gruß Jens

[Jürgen Thomas]

Zitat:

Zitat von Jens Hartmann

[FRAGE]wie bekommt man eigendlich das 'alex hat geschrieben' an die Stelle von Zitat:[FRAGE ENDE]

Ausprobieren: Drücke vor der nächsten Antwort auf den Zitat-Button; dann wird es dir vorbereitet mit quote-Tags, Gleichheitszeichen und Autor in Gänsefüßchen.

An manchen Stellen ist IBExpert in der Tat sehr restriktiv. Aber gerade den PK kannst du doch relativ einfach ausschalten, dann die Domain ändern und danach den PK neu setzen.

Gruß Jürgen