Daten ohne DBGrid

[Kathmai]

Hallo Community,

die Suche habe ich schon bemüht (irgendwie), nur wenn man leider nicht weiß nach was man genau suchen muss ist das schwierig.

Bis jetzt bin ich/wir immer ohne DBMS in unserer Firma ausgekommen - zumindest was Eigenentwicklungen angeht. Wir haben einen Urlaubsplaner der von mir in Excel geschrieben wurde im Einsatz (siehe Screenshot). Mehrbenutzerfähigkeit kann man natürlich vergessen dabei...

Ich habe mir in der letzten Zeit ausgiebig Lehrvideos und Tutorials angesehen und erste "Gehversuche" mit Firebird / FireDAC gemacht.

Wo ich nun hänge ist, ich brauche bei der Umsetzung kein DBGrid oder sonstiges. Die Daten die in der DB gespeichert sind (geht eigentlich nur um Mehrbenutzerfähigkeit) werden in einer eigenen Komponente (VCL) dargestellt. Ähnlich wie im Screenshot mit Kürzeln und paar weiteren Infos.

Wie kann ich nun die Daten aus einem Dataset (?) auslesen (sowie schreiben) und wie bekomme ich diese Infos geliefert - als records / strings ect ?

Oder anders gesagt wie würdet Ihr das Umsetzen was ich da vorhabe... Ist Firebird das richtige oder PostgresSQL über FireDAC oder lieber UniDAC?

Wäre für jede Hilfe dankbar.

Gruß
Kathmai

Edit: Es sollen ca. 4-6 Leute darauf zugreifen... Problem bei Excel war/ist, daß es die meisten nach der Bearbeitung Excel aufließen und irgendwann in unregelmäßigen Abständen nach dem Schließen / beenden eine Fehlermeldung gab mit ungefähr "Kann nicht bearbeitet werden .- durch Benutzer tt_customer geöffnet" obwohls keiner mehr auf hatte.

[hoika]

Hallo,
such dir ein Tutorial über Queries.

SQL:
Select * From
Insert Into

usw.

[juergen]

Hallo,

Zitat:

Zitat von Kathmai (Beitrag 1361467)

Oder anders gesagt wie würdet Ihr das Umsetzen was ich da vorhabe... Ist Firebird das richtige oder PostgresSQL über FireDAC oder lieber UniDAC?

Welche DB du nimmst ist *für diese Anforderung* egal.
Welche DB-Komponente du *für diese Anforderung* nimmst ist auch egal. FireDac ist um einiges teurer und ist immer an deine gekaufte Delphi-Version gebunden.
UNIDAC gibt es für jede Delphiversion, auch bei nachfolgenden Updates, ist also ein Vorteil. Wenn du nicht auf den Servermode von DevExpress angewiesen bist würde ich UNIDAC nehmen.
Oder hast du schon FireDAC? =>

Zitat:

Zitat von Kathmai (Beitrag 1361467)

erste "Gehversuche" mit Firebird / FireDAC gemacht...

Da du schon eine Komponente für die Visualisierung hast... Ist diese nicht datengebunden?

Eine Query kannst du in etwa so auslesen:

Code:

  Query1.First;
  while not(Query1.eof) do begin
    for i := 0 to Query1.FieldCount - 1 do begin
      // füllen deines Grids
    end;
    Query1.Next;
  end;

[Kathmai]

Zitat:

Zitat von juergen (Beitrag 1361475)

Oder hast du schon FireDAC?

Chef hat damals in weißer vorraussicht D10.1 Pro + FireDAC Addon bezahlt für Firma - wäre mir zu teuer. Pro selbst ist schon nicht gerade "preiswert".

Zitat:

Zitat von juergen (Beitrag 1361475)

Da du schon eine Komponente für die Visualisierung hast... Ist diese nicht datengebunden?

Jaein - bin grad am Entwickeln. Bin bei der Komponente noch am tüfteln zwecks Drucken (Canvas über Parameter - Print und Paint).

Hab schon mittlerweile durch den Tip von hoika mich mit den FDQuery beschäftigt und schon gefilterte Spalten in Memofelder "geschoben" damit. Hänge gerade bei den Parametern fest. Nur Verbindung über Teamviewer ist lahm da machts net wirklich Spaß zu arbeiten...

IBDac/UniDac würde mir persönlich besser gefallen weil nicht gebunden - und kosten tun sie verhältnismäßig auch net viel bei 290 bzw. 430€ netto.

Hab noch viel zu lernen / testen mit Datenbanken.

Aber der Tip mit Query's hat schon viel geholfen danke.

[Slipstream]

Zitat:

Zitat von Kathmai (Beitrag 1361467)

Hallo Community, die Suche habe ich schon bemüht (irgendwie), nur wenn man leider nicht weiß nach was man genau suchen muss ist das schwierig.

Einen Kalender mit Firebird und IbDac unter Delphi 2010 hab ich auch schonmal gebaut. War Teil einer umfangreichen Terminverwaltung für eine größere Firma. Für die Darstellung der Termine hab ich dennoch Grids verwendet, jedoch kein DBGrid, sondern StringGrids.

Am besten du fängst mit Konfiguration der Datenbank an. Dazu lädst du dir den Datenbankmanager von IbExpert herunter, der ist in der Personalversion kostenlos, das reicht in den meisten Fällen aus. Um die persönlichen Einstellungen der Benutzer ebenfalls in der Datenbank zu speichern, legst du eine Benutzertabelle an, die in ihren Spalten alle Optionen enthält, die der Benutzer abspeichern kann. Damit wäre erstmal gewährleistet, daß die Benutzereinstellungen auch beim Rechnerwechsel verfügbar bleiben.

Im Menü Datenbank des IBExpert Datenbankmanagers wählst du dein Eintrag Datenbank erzeugen. Befindet sich Firebird-Server und Datenbank auf deinem Arbeitsrechner, wählst du als Server local aus, ansonsten Remote und das entsprechende Protokoll. Beim lokalen Server musst du Servername und Port nicht angeben. Danach wählst du den Datenbanknamen. Der Eintrag Clientbibliothek sollte die fbclient.dll im Order Windows/System32 beinhalten. Die anderen Einträge sind selbsterklärend.

Benötigst du Boolean-Felder in deinem Projekt, must du dir erstmal eine Boolean-Definition anfertigen. Dazu doppelklickst du erstmal auf deine frisch angelegte Datenbank, worauf sich der Datenbank-Tree öffnet. Ganz oben wählst du mittels Rechtsklick Neue Domäne. Dort gibst du dann als Name z.B. MYBOOL an. Die Boolean-Deklaration verlangt einen Bezeichner, der die Zeichenfolge bool beinhaltet. Als Feldtyp wählst du SmallInt, weil Firedac das so erwartet, Unidac verlangt hier z.B. Integer. Das Feld Nicht Null wird angekreuzt. Standardquelle ist z.B. 0, das steht für False, oder 1, das wäre True. Im Feld Check steht VALUE IN (0,1), in die Feldbeschreibung kannst du reinschreiben, was du möchtst.

Dann klickst du mit rechts auf Tabellen und wählst Neue Tabelle. Dort trägst du zuerst den Tabellen-Namen ein, z.B. USERDATA. Dann legst du einen Primary Key an. Mit einem Doppelklick in das Feld PK wird diese Spalte deiner neuen Tabelle zum Hauptschlüssel. Als Feldname wählst du z.B. ID_USERDATA oder was auch immer. Um bei jedem neuen Datensatz automatisch den PrimaryKey hochzuzählen, machst du einen Doppelklick auf das Feld AI und erzeugst im erscheinenden Dialog einen Generator, einen Trigger und eine Prozedur.

Danach legst du weitere Userdaten-Spalten an, z.B. Username und Passwort für den Programmzugriff, Breite und Position des Programmfensters und alles sonst, was dein Herz begehrt. Hast du die Tabelle USERDATA fertig, klickst du auf den Blitz oben links und kompilierst deine Eingaben. Danach hast du eine Tabelle USERDATA, jedoch ohne Einträge. Die ersten Einträge machst du am besten auch mit dem IbExpert, indem du auf den Dateireiter Daten klickst, wo du dann Daten eingeben kannst.

Das wäre also der Schnelleinstieg in die Datenbankentwicklung.

Dann legst du in deinem Delphi-Projekt erstmal ein Datenmodul an. Dort hinein kommen dann alle Datenbank-Komponenten. In den Units, die dann Datenbank-Konnektivität benötigen, fügst du die Datenmodul-Unit in die Uses ein, das kann auch im Implementierungabschnitt geschehen.

Wenn du mit Firedac arbeitest, ist ein bisschen was zu beachten. Zuerst benötigst du eine TFdConnection, das ist die Datenbankverbindungskomponente. Danach benötigst du aber auch gleich mindestens eine TFDTransaction, besser zwei, weil du dann für normale Transaktionen und für Update-Transaktionen unterschiedliche Komponenten verwenden kannst. Des weiteren brauchst du einen TFDGUIxWaitCursor und einen TFDPhysFBDriverLink auf dem Datenmodul.

Beim Entwickeln stellst du das Property LoginPromt deiner TFdConnection erstmal auf False, damit du nicht bei jedem Testlauf die Anmeldedaten (Username und Passwort) für den Firebird-Server eingeben musst. Nun gehst du zum Property Params Als Characterset stellst du das ein, was du beim Anlegen deiner Datenbank eingestellt hast. Ich würde hier von vorneherein zu UTF8 raten, was du damit alle verfügbaren Zeichen in Strings verwenden kannst. Unter Database gibst du den vollständigen Datenbank-Namen (=mit Pfadangaben) ein oder wählst ihn aus dem Dateidialog. Ganz wichtig, wenn du Boolean-Felder verwenden willst: Das Property ExtendedMetaData muss auf True stehen. Als SQL-Dialekt sollte 3 gewählt werden, in den Properties Password und Username sollten gültige Daten stehen. Ganz unten stehen dann noch die Properties Transaction und UpdateTransaction aus, wo du deine beiden Transaktionskomponenten einstellst.

Wenn du alles richtig gemacht hast, sollte ein Klick auf das Property Connected die Verbindung zur Datenbank herstellen.

Nun legst du ein TFDQuery auf das Datenmodul. Hast du nur eine Datenbank-Komponente auf dem Modul, wird diese beim Query automatisch eingetragen. Im Query suchst du zuerst das Property SQL auf und trägst dort z.B. ein: select * from Userdata. Das wäre deine Tabelle Userdata in der Datenbank. Unter Transaction und UpdateTransaction wählst du die beiden Transaktionskompenten, die sinnvollerweise entsprechende Bezeichner tragen, z.B. TransMain und TransUp. In den UpdateOptions trägst du nun unter AutoIncFields den Primary-Key ein, wenn du ihn in der Datenbank bereits als automatisch hochzählendes Feld angelegt hast. Unter Generatorname kommt der FB-Generator rein, und unter KeyFields wieder der Primary-Key. Unter UpdateTableName kommt der Tabellenname rein.

Wenn du alles richtig gemacht hast, sollte ein Click auf das Property Active die Datensatzmenge aus der Datenbank ins Query laden. Ein Doppelklick auf das Query öffnet den Abfrage-Editor, wo du die Inhalte der Tabelle abrufen kannst.

So, das war jetzt eine Kurzanleitung zum Einstieg. Morgen bei Bedarf weiteres.

[jobo]

Zitat:

Zitat von Kathmai (Beitrag 1361481)

Hab schon mittlerweile durch den Tip von hoika mich mit den FDQuery beschäftigt und schon gefilterte Spalten in Memofelder "geschoben" damit. Hänge gerade bei den Parametern fest. Nur Verbindung über Teamviewer ist lahm da machts net wirklich Spaß zu arbeiten...

Wenn Du per Query bereits Daten holen kannst, dann kannst Du per Query auch Daten ändern oder einfügen.
Daten holen: Select ...
Daten ändern: Update ...
Daten einfügen: Insert ...
Löschen: Delete ...

[haentschman]

Moin...:P

@Alle
Ich fasse mal zusammen:
1. Firebird... Gute Wahl :P
2. UniDAC... es haben alle Zugriffskomponenten ihre Eigenarten. Bei mir waren es die Updates, die unabhängig vom Delphi zur Verfügung stehen und der Preis.
3. Query ist dein Sichwort... aus welcher Komponente ist egal (UniDAC etc.)

Was ich anders machen würde (für die Zukunft) :wink::

Zitat:

Dann legst du in deinem Delphi-Projekt erstmal ein Datenmodul an.

*möööp* Für jede Query eine Komponente auf dem Datenmodul + Connection + etc. Ich habe schon Datenmodule mit mehr als 100 Querys gesehen. Wer hat da noch den Überbick. Alle Querys auf dem Datenmodul werden automatisch erzeugt obwohl sie vieleicht einmal gebraucht werden.

Zitat:

Im Query suchst du zuerst das Property SQL auf und trägst dort z.B. ein: select * from Userdata...
Wenn du alles richtig gemacht hast, sollte ein Click auf das Property Active die Datensatzmenge aus der Datenbank ins Query laden. Ein Doppelklick auf das Query öffnet den Abfrage-Editor, wo du die Inhalte der Tabelle abrufen kannst.

*möööp* Das ist zwar einfach das SQL einzutragen aber du verteilst die SQL komplett auf den Quelltext z.B. auf die Komponenten.
*möööp* Niemals die Property ACTIVE auf TRUE im OI setzen.
*möööp* Die Inhalte der Tabelle werden / sollten mit einem vernüftigen externen Editor angezeigt werden.

Zitat:

Beim Entwickeln stellst du das Property LoginPromt deiner TFdConnection erstmal auf False, damit du nicht bei jedem Testlauf die Anmeldedaten (Username und Passwort) für den Firebird-Server eingeben musst.

*möööp* Auch wenn es funtioniert...Die Anmeldedaten der DB haben nichts im QT oder Komponente zu suchen. Eine externe Speicherung ist dein Freund (INI etc.)

Meine Tipps (meine Meinung :wink:):
1: !!! keine DB Komponenten
* Am Anfang ist das sicher einfacher. Mit steigenden Anforderungen kommst du da nicht mehr zurecht. (Joins und der Speicherung der Selben etc.) Du nimmst dir Gestaltungsmöglichkeiten weil es die Komponente nicht als DB Version gibt. Wie schon gesagt ist ein StringGrid, in deinem Falle, eine Alternative.
2: Vermeidung einer direkten permanenten DB Verbindung mit Querys im Netzwerk
* Der Letzte der den Datensatz schreibt hat gewonnen. (in Milisekunden) Wenn die Putze über das Netzwerkkabel stolpert sind alle Transaktionen "geschrieben" :wink:
3: Kapselung des DB Zugriffs in einem Interface oder einer abstrakten Klasse statt DB Module
* Mein DB Interface hat eine procedure z.B. FillList(MeineList: TBlubbList). Die Anwendung übergibt die Liste, das Interface füllt sie aus und die Anwendung arbeitet damit. Dabei ist es unerheblich wo die Daten herkommen...aus DB1, DB2, Omas Kleiderschrank...8-) Hier hat man die Trennung.
* Die Instanz des Interfaces / Klasse kann problemlos mehrfach nach Bedarf erzeugt werden. Mit einem automatisch generieren Datamodule geht das eher nicht.
* Alle DB Interaktionen sowie die SQL Statements und deren Parameter sind im Qelltext vorhanden.
* Ein Austausch der DB Komponenten ist "einfach" möglich. Stelle dir mal vor, die SQL Statements müßtest du auch in die neue Komponente übertragen. :? Viel Spaß...
4: Arbeiten mit Datenobjekten
* Ein Objekt repräsentiert Daten die ggf. aus verschieden Tabellen stammen können. (Join) Die Daten werden mit einer Query, die erzeugt wird, aus verschiedenen Tabellen geholt. Damit hat die Query ihre Arbeit erledigt und kann freigegen werden. Später "dröselt" die Datenbankklasse das Objekt wieder auf und speichert die Daten in die entsprechenden Tabellen. (7)
* Das Objekt läßt sich gut debuggen. :thumb: (Inhaltsanzeige)
5: Ablage der Datenobjekte
* http://docwiki.embarcadero.com/Libra...ns.TObjectList
6: Ablage der SQL
* Je nach Projekt kann man auch die SQL Statements in einer Ressource vorhalten. http://www.delphipraxis.net/49505-sq...einbinden.html
* ! WERBUNG :wink:: Der Ressource Creator hilft dir dabei. http://www.delphipraxis.net/190316-d...creator-2.html
7: Normalisierung der Datenbank
* Die Normalisierung kann man auch auf die Spitze treiben. :wink: Aber die Trennung von Master / Detaildaten ist wichtig. Wenn man die Normalisierung einsetzt, hat man keine Chance DB Komponenten zu verwenden. (Joins)
https://de.wikipedia.org/wiki/Normal...ng_(Datenbank)

Wie du siehst, eine Datenbank ist nicht nur eine Datenbank. Man kann vieles falsch machen was man dann später wieder mühsam korrigieren muß. :? Mach dir ein Testprogramm um die verschieden Varianten zu testen ohne im Produktivcode was zu ändern. Wenn du dich für eine Variante entschieden hast, dann kannst du dich auf dein Programm loslassen... :wink: Manche Varianten sind mit mehr Schreibarbeit verbunden was sich später hinaus wieder rechnet...Übersicht, Testbarkeit, mehrere DBMS usw.

Alle Entwickler haben so ihre Varianten... :thumb: Du mußt nur das für dich passende raussuchen.

[p80286]

Zitat:

Zitat von haentschman (Beitrag 1361491)

Zitat:

Dann legst du in deinem Delphi-Projekt erstmal ein Datenmodul an.

*möööp* Für jede Query eine Komponente auf dem Datenmodul + Connection + etc. Ich habe schon Datenmodule mit mehr als 100 Querys gesehen. Wer hat da noch den Überbick. Alle Querys auf dem Datenmodul werden automatisch erzeugt obwohl sie vieleicht einmal gebraucht werden.

Wer macht den sowas?

Um ein Stringgrid zu befüllen würde sich meiner Meinung nach eine Stringliste anbieten, das scheint mir am flexibelsten. Wenn die meisten Daten in ein record passen, bist Du mit einer Liste allerdings besser bedient.
das sieht dann im Prinzip so aus: (pseudocode)

Delphi-Quellcode:

var 
  datenliste : tstringlist;
  mysqltext : string;

begin
  datenliste:=TStringlist.Create;
  HoleDatenperQuery(mysqltext,datenliste);
  if datenliste.count>0 then
    FülleStringgrid(datenliste);
  Datenliste.free;
end;

Die TStringlist kannst Du natürlich durch jeden ListenTyp ersetzen, der Dir besser geeignet scheint.


Gruß
K-H

[Slipstream]

Zitat:

Zitat von haentschman (Beitrag 1361491)

Alle Entwickler haben so ihre Varianten... :thumb: Du mußt nur das für dich passende raussuchen.

Das ist auf jeden Fall immer richtig, und es kommt auch darauf an, was das für eine Anwendung ist. Wir haben hier zum Bispiel langjährig gepflegte Grossprojekte für Multiuser im Netzwerk, da arbeiten wir selbstverständich auf Sicherheit: Die Rechner besitzen alle mindestens 16 Gigabyte Ram, ein Großteil der benötigten Daten wird über Objektlisten im Speicher vorgehalten, nicht mehr benötigte Daten werden zurückgeschrieben und die Objektlisten freigegeben.

Wir haben aber auch Kleinprojekte für kleinere Firmen oder für den Massenmarkt, da arbeiten wir anders, weil hier nich so viel Profit drin ist und wir deshalb schneller entwickeln müssen - das berühmte RAD. Meistens sind das auch lokale Anwendungen, die mit Embedded-FB ausgestattet sind. Da braucht man diese Sicherheitsvorkehrungen weger der Putzfrau nicht wirklich. Einige Projekte haben wir übernommen und müssten die neu aufbauen, wenn wir dort immer höchste Sicherheit haben wollten.

Mein Beitrag sollte nichts anderes sein als ein einfacher Einstieg ins Datenbankmilieu. :-D
Weil sowas wies scheint nicht erwünscht ist, lass ichs in Zukunft natürlich gerne bleiben. Ich möcht hier keinen konkurrieren.

[p80286]

Zitat:

Zitat von Slipstream (Beitrag 1361531)

Mein Beitrag sollte nichts anderes sein als ein einfacher Einstieg ins Datenbankmilieu. :-D
Weil sowas wies scheint nicht erwünscht ist, lass ichs in Zukunft natürlich gerne bleiben. Ich möcht hier keinen konkurrieren.

Nö warum? Das wäre ein Weg zum Ziel, und wahrscheinlich der, der das schnellste Erfolgserlebnis verspricht.
Nur z.B. active im OI auf true zu setzen, kann gewaltig in die Hose gehen, falls mal die Datenbank nicht verfügbar ist. Das muß man wissen! ansonsten sind wir hier nicht einer Meinung was Datenbanken und ihre Anbindung angeht, und das ist auch gut so, dann hat man immer die Möglichkeit seine eigene Herangehensweise zu überprüfen.

Gruß
K-H

[Slipstream]

Der ursprüngliche Fragensteller hatte doch deutlich gesagt, dass er neu im Datenbankmetier ist: "Bis jetzt bin ich/wir immer ohne DBMS in unserer Firma ausgekommen - zumindest was Eigenentwicklungen angeht."

Wieso soll man so jemandem dann die allerkompliziertesten Möglichkeiten anbieten? Meinst du nicht, dass der sich davon erschlagen fühlen muss? Ich habs nur gut gemeint. Wenn man mir das vor 20 Jahren so hochkompliziert erklärt hätte, hätte ichs damals nicht begriffen, glaub ich. Aber gleich sagen: So macht man das nicht, da muss man noch dieses und alles das und sonstnochwas beachten. Er will doch nur eine multiuserfähige Urlaubsplanung basteln. Und während die Leute ihre Urlaube eintragen, wedelt meistens sowieso keine Putzfrau mit den Netzwerkkabeln rum, oder? Die kommt doch erst nach Feierabend oder vor Bürobeginn. Schliesslich hab ich unseren Teamkalender (Terminkalender) auch in ein paar Tagen fertiggestellt, und das ganz ohne diese ganzen Sicherheitsbedenken. Den meisten Aufwand hat die Rechnerei mit den Tagen benötigt, und die Darstellung im StringGrid. Wenn man aber Anfänger in Sachen Datenbank ist, dann muss man da schon ein bissel früher ansetzen.

[Kathmai]

Hallo,

@Slipstream:
Ja bin neu im DB Metier. Und vielen Dank für Deinen ausführlichen Beitrag.
Den IBExpert hatte ich mir schon vorher besorgt da das pgAdmin Tool von PostgresSQL nur rumgesponnen hat.

Einige Dinge hab ich mir schon vorher angeschaut um nicht blauäugig an die Sache ranzugehen.

Das mit der Domäne in Bezug auf den Boolean Wert wusste ich auch noch nicht - hab aber nachgeschaut daß Firebird 3.0 den Boolean Wert jetzt nativ unterstützt. Kann man doch gleich auf Firebird 3.0 gehen. Aber kann mich auch dran erinnern hier mal vor ein paar Monaten ein Thread gesehen zu haben der sich mit Firebird und Windows beschäftigt.

Bei Win 7 funktioniert FB3 bei allen anderen spackt FB irgendwie noch rum - ist das noch aktuell?

Hab jetzt in einer VM unter Win7 den Superserver 2.5 in 64 bit laufen. Bis auf daß FireDAC beim Design rum motzt (is ja klar - weil Delphi selbst 32 bit ist) aber zur Laufzeit vom Testprogramm funktioniert alles mit der 64bit Version.

@haentschman:
Muss "leider" bei FireDAC bleiben - Chef will (vorerst) keine Kohle für UniDac rausrücken...

Zitat:

Zitat von haentschman (Beitrag 1361491)

*möööp* Niemals die Property ACTIVE auf TRUE im OI setzen.

Hab ich im RAD Wiki auch so gelesen. Benutze fdquery.open

Zitat:

Zitat von haentschman (Beitrag 1361491)

* Am Anfang ist das sicher einfacher. Mit steigenden Anforderungen kommst du da nicht mehr zurecht. (Joins und der Speicherung der Selben etc.) Du nimmst dir Gestaltungsmöglichkeiten weil es die Komponente nicht als DB Version gibt. Wie schon gesagt ist ein StringGrid, in deinem Falle, eine Alternative.

StringGrid ist keine alternative. Es gibt paar Punkte die nicht davon abgedeckt werden können. Mit Aufwand zum umschreiben schon, aber den kann ich nicht abschätzen. Jedesmal bei einer neuen Testversion kommt Cheffe - hey, das könnte ja noch rein und das und das und das... Kommt jetzt nicht mit Pflichten/Lastenheft - bin hier festangestellt. Mir solls schnuppe sein ;-)

Zitat:

Zitat von haentschman (Beitrag 1361491)

Wie du siehst, eine Datenbank ist nicht nur eine Datenbank. Man kann vieles falsch machen was man dann später wieder mühsam korrigieren muß. Mach dir ein Testprogramm um die verschieden Varianten zu testen ohne im Produktivcode was zu ändern. Wenn du dich für eine Variante entschieden hast, dann kannst du dich auf dein Programm loslassen... Manche Varianten sind mit mehr Schreibarbeit verbunden was sich später hinaus wieder rechnet...Übersicht, Testbarkeit, mehrere DBMS usw.

Ja sicher, ist schon ne ganz andere Sache als typisierte/untypisierte Dateien zu verwenden. Aber die Möglichkeiten sind schon klasse. Wobei manchmal ne DB einfach wie auf Spatzen mit Kanonen geschossen bedeutet.

Gibt ein gutes Tutorials bei Video2brain über Datenbank Design - zwar nur für Acccess aber gut zu wissen um nicht mehrfach anfängen zu müssen weil man einfach drauf los programmiert hat.

Zitat:

Zitat von Slipstream (Beitrag 1361572)

Wieso soll man so jemandem dann die allerkompliziertesten Möglichkeiten anbieten? Meinst du nicht, dass der sich davon erschlagen fühlen muss? Ich habs nur gut gemeint. Wenn man mir das vor 20 Jahren so hochkompliziert erklärt hätte, hätte ichs damals nicht begriffen, glaub ich.

Klar wird man erschlagen als Anfänger und die Tutorials auf Delphi-Treff sind ja sowas vom letzten Jahrhundert.
Derjenige der sich damit auskennt wird viellicht sagen, daß es ausreichend ist. Ist es nicht. Besonders in Bezug auf aktuelle Versionen der Zugriffskomponenten und auch evtl. der Datenbanken.

Wie soll nun ein Anfänger verstehen wenn was nicht funktioniert wenn Funktionen / Methoden oder sonstige Techniken nicht mehr in z.b. in ZEOS gibt und der Compiler rummeckert?!

Aber --- jeder hat mal klein angefangen. Und Tutorials gibts im Netz zu Hauf auch auf Deutsch und aktuell.
Wenn das nix bringt - nerven wir Euch einfach ;-)

Danke nochmal an alle für die Tips.

Werde sehr viel testen die nächste Zeit.
Was die DB angeht ob ich/wir dann nun FB2.5 oder FB3 einsetzen werden - mal sehen.

Gruß
Thomas

[Slipstream]

Zitat:

Zitat von Kathmai (Beitrag 1361598)

@Slipstream:
Ja bin neu im DB Metier. Und vielen Dank für Deinen ausführlichen Beitrag.

Das freut mich jetzt aber, dass ich das nicht ganz umsonst geschrieben habe. :-D

Zitat:

Zitat von Kathmai (Beitrag 1361598)

Den IBExpert hatte ich mir schon vorher besorgt da das pgAdmin Tool von PostgresSQL nur rumgesponnen hat.

Ich kann mir ein Leben ohne gar nicht mehr vorstellen, das ist ein echt brauchbares Tool. :)

Zitat:

Zitat von Kathmai (Beitrag 1361598)

Einige Dinge hab ich mir schon vorher angeschaut um nicht blauäugig an die Sache ranzugehen.

Da kommt man nicht drum herum, will man nicht unnötige Umwege gehen.

Zitat:

Zitat von Kathmai (Beitrag 1361598)

Das mit der Domäne in Bezug auf den Boolean Wert wusste ich auch noch nicht - hab aber nachgeschaut daß Firebird 3.0 den Boolean Wert jetzt nativ unterstützt. Kann man doch gleich auf Firebird 3.0 gehen.

Ja, das ist richtig, aber ich setze noch immer die 2.5er Version ein, die läuft seit Jahren stabil. So lange wir keine verschlüsselte Datenbank benötigen, genügt diese Version auch.

Zitat:

Zitat von Kathmai (Beitrag 1361598)

Bei Win 7 funktioniert FB3 bei allen anderen spackt FB irgendwie noch rum - ist das noch aktuell?

Keine Ahnung, ob das noch aktuell ist. Ich werde erst dann auf FB3 umsteigen, wenn die "Kinderkrankheiten" ausgebessert wurden. Und darüber lese ich dann auch erstmal in den Foren, was FB3 noch an Problemen zu bieten hat. Fürs Testen der neuen FB3-Version werden wir nicht bezahlt, so unser Cheffe.

Zitat:

Zitat von Kathmai (Beitrag 1361598)

Hab jetzt in einer VM unter Win7 den Superserver 2.5 in 64 bit laufen. Bis auf daß FireDAC beim Design rum motzt (is ja klar - weil Delphi selbst 32 bit ist) aber zur Laufzeit vom Testprogramm funktioniert alles mit der 64bit Version.

Es gibt für Delphi zwei verschiedene fbclient.dll, einmal für 32 bit (Dateigrösse bei mir 552.960) und einmal für 64 bit (874.496). Das bezieht sich aber auf die Anwendung und nicht auf die Firebird-Version. Hast du einen 32-Bit-FB-Server installiert, hast du wieder andere DLL-Versionen. Natürlich kannst du mit einer 32-Bit-Anwendung auch auf einen 64-Bit-FB-Server zugreifen. Anfernfalls könnte ich hier keine 32-Bit-Datenbankanwendung kompilieren oder ausführen. Ansonsten weiss ich jetzt nicht, was du mit "motzt rum" genau meinst. Bei uns hier funktioniert das alles tadellos mit demselben FB-Server mit Firedac sowie mit Devarts Unidac oder IbDac. (Zeos verwenden wir nicht, ich privat unter CodeTyphon aber schon.) Für Kunden, die keinen FB-Server installiert haben oder das nicht wollen, bieten wir immer auch die Embedded-Variante an. Die ist dann nur eingeschränkt multiuserfähig. Bei gewünschter Multiuserfähigkeit können wir unsere Kunden immer davon überzeugen, einen FB-Server zu installieren. Ohne FB-Server funktioniert z.B. die Änderungsbenachrichtigung (TFDEventAlerter) nicht, weil da jeder Client praktisch seinen eigenen FB-Server betreibt (in Form der Embedded-DLL).

Zitat:

Zitat von Kathmai (Beitrag 1361598)

@haentschman: Muss "leider" bei FireDAC bleiben - Chef will (vorerst) keine Kohle für UniDac rausrücken...

Das ist nach meiner Erfahrung auch nicht nötig. Wir haben keinerlei Probleme mit Firedac, im Gegensatz zu anderen Komponenten, die wir früher hatten, u.a. FibPlus, UIB, IBX, IBObjects. Die sind veraltet.

Zitat:

Zitat von Kathmai (Beitrag 1361598)

Zitat:

Zitat von haentschman (Beitrag 1361491)

*möööp* Niemals die Property ACTIVE auf TRUE im OI setzen.

Hab ich im RAD Wiki auch so gelesen. Benutze fdquery.open

Ich mache das weiterhin so, wenn es erforderlich ist, wenn ich z.B. einen Filter testen will. Man darf nur nicht vergessen, vor dem Testdurchlauf (F9) die Connection zu deaktivieren. Schon wenn ich persistente Felder anlege, verbindet sich die FBConnection automatisch (Connected = True).

Zitat:

Zitat von Kathmai (Beitrag 1361598)

Zitat:

Zitat von haentschman (Beitrag 1361491)

* Am Anfang ist das sicher einfacher. Mit steigenden Anforderungen kommst du da nicht mehr zurecht. (Joins und der Speicherung der Selben etc.) Du nimmst dir Gestaltungsmöglichkeiten weil es die Komponente nicht als DB Version gibt. Wie schon gesagt ist ein StringGrid, in deinem Falle, eine Alternative.

StringGrid ist keine alternative. Es gibt paar Punkte die nicht davon abgedeckt werden können. Mit Aufwand zum umschreiben schon, aber den kann ich nicht abschätzen. Jedesmal bei einer neuen Testversion kommt Cheffe - hey, das könnte ja noch rein und das und das und das... Kommt jetzt nicht mit Pflichten/Lastenheft - bin hier festangestellt. Mir solls schnuppe sein ;-)

Wir verwenden hier meistens das TjvDBGrid aus den Jedi-Komponenten, das kann ein bisschen mehr als das mitgelieferte TDBGrid. Bis jetzt hatten wir damit keine Probleme und konnten alle anfallenden Aufgaben damit lösen.

[Kathmai]

Schiebt da jemand auch Nachtschichten?!

Zitat:

Zitat von Slipstream (Beitrag 1361600)

Es gibt für Delphi zwei verschiedene fbclient.dll, einmal für 32 bit (Dateigrösse bei mir 552.960) und einmal für 64 bit (874.496). Das bezieht sich aber auf die Anwendung und nicht auf die Firebird-Version. Hast du einen 32-Bit-FB-Server installiert, hast du wieder andere DLL-Versionen. Natürlich kannst du mit einer 32-Bit-Anwendung auch auf einen 64-Bit-FB-Server zugreifen.

Danke. Wusste ich auch noch nicht, das man mit einer 32bit auf nen 64bit FB Server zugreifen kann.

Bei der FBclient.dll in 64bit meckerte FireDAC Rum daß es die falsche Version sei. Man kann also nicht die DB Verbindung zur Designtime testen...

[hoika]

Hallo,
dann installier doch gleich den 32Bit-Server.
Ich empfehle auch, noch die 2.5-Version zu benutzen.

Und: Guten Morgen :)

[hoika]

Hallo,

Zitat:

Bei der FBclient.dll in 64bit meckerte FireDAC Rum daß es die falsche Version sei. Man kann also nicht die DB Verbindung zur Designtime testen...

Zur Not einfach das 32Bit-Client-Setup zusätzlich installieren,
das sollte die FBClient.Dll in das SysWOW64-Verzeichnis installieren.

Wobei mir unklar ist, wieso die Designtime nicht funktioniert, aber die Runtime klappt.

[Slipstream]

Zitat:

Zitat von Kathmai (Beitrag 1361601)

Schiebt da jemand auch Nachtschichten?!

Zitat:

Zitat von Slipstream (Beitrag 1361600)

Es gibt für Delphi zwei verschiedene fbclient.dll, einmal für 32 bit (Dateigrösse bei mir 552.960) und einmal für 64 bit (874.496). Das bezieht sich aber auf die Anwendung und nicht auf die Firebird-Version. Hast du einen 32-Bit-FB-Server installiert, hast du wieder andere DLL-Versionen. Natürlich kannst du mit einer 32-Bit-Anwendung auch auf einen 64-Bit-FB-Server zugreifen.

Danke. Wusste ich auch noch nicht, das man mit einer 32bit auf nen 64bit FB Server zugreifen kann.

Bei der FBclient.dll in 64bit meckerte FireDAC Rum daß es die falsche Version sei. Man kann also nicht die DB Verbindung zur Designtime testen...

Wenn du damit meinst, dass wenn du in der Projektverwaltung die Zielplattform auf 64-Bit-Windows umschaltest, das Setzen deiner TFDConnection auf Connected := True nicht funktioniert, kann ich das hier nicht nachvollziehen. Bei mir funktioniert das. Hier auf meinem Entwicklungsrechner befindet sich die fbClient.dll für den 32-Bit-Client (552.960 Bytes) in den beiden Verzeichnissen C:\Windows\SysWOW64 und C:\Windows\System32. Ein Versuch, die fbclient.dll für den 64-Bit-Client (874.496 Bytes) in eines der beiden Verzeichnisse zu kopieren, scheiterte auch mit Administratorrechten (DOS-Box als Admin aufgerufen). Also verwendet Designtime ausschliesslich die kleinere fbClient.dll.

Die Komponente TFDPhysFBDriverLink verfügt über die beiden Properties VendorHome und VendorLib. Hier trage ich gewöhnlich nichts ein.

In den jeweiligen Release-Ordnern des Projekts stehen dann auch immer die entsprechenden Versionen von fbClient.dll, die ich im Code vor dem Herstellen der DB-Connection (Connected := True) die jeweilige fbClient.dll zuweise. Soll es eine Embedded-Version werden (wenn der Kunde keine FB-Server-Installation hat oder will), wird auch die entsprechende Embedded-Dll mitgeliefert, die dann ebenfalls im Anwendungsordner zu finden ist. Bis jetzt hatten wir damit keine Probleme. Hat ein Kunde mal ein Problem, weil er eine ältere FB-Version verwendet, überreden wir ihn meisten dazu, die neuere 2.5x Version zu installieren oder die Client-Dll aus seiner alten FB-Version in den Programmordner zu kopieren. Manchmal nimmt ein solcher Kunde dann doch lieber gleich die Embedded-Version, wenn sichs um eine Einzelplatzanwendung handelt.

Ja, Nachtschichten mach ich hier oft, aber nicht gewzungenermassen, denn wir können hier arbeiten, wann und wie lange wir wollen. Manchmal bin ich nachts zu ausgeschlafen, um einschlafen zu können, dann geh ich ein paar Häuser weiter ins Büro und arbeite mich müde. Könnte ich auch von zu Hause aus, aber da haben wir nur Laptops, und ich arbeite mit meinen Wurstfingern nicht gern an Laptops. Meine Frau freut sich, wenn ich mittags schon zu Hause bin und mit den Kindern was mache, die freuen sich auch. Nachts braucht mich zu Hause keiner :-D

[hoika]

Hallo,

Zitat:

oder die Client-Dll aus seiner alten FB-Version in den Programmordner zu kopieren

Das könnte Probleme geben.
Zumindestens in den seeligen FB1-er Zeiten konnte das im schlimmsten Fall dazu führen,
dass die DB-Datei zerschossen wurde (z.B. also das Trim bei der Übermittlung von VarChar-Feldern eingeführt wurde, glaub ich)

Zitat:

und ich arbeite mit meinen Wurstfingern nicht gern an Laptops.

Laptop + externe Tastatur + Monitor ...

Zitat:

Nachts braucht mich zu Hause keiner

Kein Kommentar :)

[Slipstream]

Zitat:

Zitat von hoika (Beitrag 1361641)

Hallo,

Zitat:

oder die Client-Dll aus seiner alten FB-Version in den Programmordner zu kopieren

Das könnte Probleme geben.
Zumindestens in den seeligen FB1-er Zeiten konnte das im schlimmsten Fall dazu führen,
dass die DB-Datei zerschossen wurde (z.B. also das Trim bei der Übermittlung von VarChar-Feldern eingeführt wurde, glaub ich)

Das vermeidet man, indem man vor der Verwendung der Datenbank-Datei einen Backup durchführt und mit der alten Version einen Restore. Das wird durch die Installatationsprogramm gelöst.