![]() |
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 ![]() 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 ![]() ![]() ![]() ![]() 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 * ![]() 6: Ablage der SQL * Je nach Projekt kann man auch die SQL Statements in einer Ressource vorhalten. ![]() * ! WERBUNG :wink:: Der Ressource Creator hilft dir dabei. ![]() 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) ![]() 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 |
AW: Daten ohne DBGrid
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. |
AW: Daten ohne DBGrid
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:
Zitat:
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:
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 |
AW: Daten ohne DBGrid
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
|
AW: Daten ohne DBGrid
Schiebt da jemand auch Nachtschichten?!
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... |
AW: Daten ohne DBGrid
Hallo,
dann installier doch gleich den 32Bit-Server. Ich empfehle auch, noch die 2.5-Version zu benutzen. Und: Guten Morgen :) |
AW: Daten ohne DBGrid
Hallo,
Zitat:
das sollte die FBClient.Dll in das SysWOW64-Verzeichnis installieren. Wobei mir unklar ist, wieso die Designtime nicht funktioniert, aber die Runtime klappt. |
AW: Daten ohne DBGrid
Zitat:
Die Komponente ![]() ![]() ![]() 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 |
AW: Daten ohne DBGrid
Hallo,
Zitat:
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:
Zitat:
|
AW: Daten ohne DBGrid
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:30 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