|
Datenbank: Firebird / PostgresSQL • Version: 2.5 / 9.6 • Zugriff über: UniDAC / FireDAC
Daten ohne DBGrid
Liste der Anhänge anzeigen (Anzahl: 1)
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. |
AW: Daten ohne DBGrid
Hallo,
such dir ein Tutorial über Queries. SQL: Select * From Insert Into usw. |
AW: Daten ohne DBGrid
Hallo,
Zitat:
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:
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; |
AW: Daten ohne DBGrid
Zitat:
Zitat:
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. |
AW: Daten ohne DBGrid
Zitat:
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. |
AW: Daten ohne DBGrid
Zitat:
Daten holen: Select ... Daten ändern: Update ... Daten einfügen: Insert ... Löschen: Delete ... |
AW: Daten ohne DBGrid
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:
Zitat:
*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:
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.TObjectList6: 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.html7: 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. |
AW: Daten ohne DBGrid
Zitat:
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:
Die TStringlist kannst Du natürlich durch jeden ListenTyp ersetzen, der Dir besser geeignet scheint.
var
datenliste : tstringlist; mysqltext : string; begin datenliste:=TStringlist.Create; HoleDatenperQuery(mysqltext,datenliste); if datenliste.count>0 then FülleStringgrid(datenliste); Datenliste.free; end; Gruß K-H |
AW: Daten ohne DBGrid
Zitat:
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. |
AW: Daten ohne DBGrid
Zitat:
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 |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 16:43 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz