15. januar 2001 - 20:24Der er
60 kommentarer og 2 løsninger
Database engine søges
Jeg står og mangler en database engine til mit program.
Det skal være gratis og lovligt at bruge/distribuere.
Det skal enten inkluderes i EXE-filen, eller det skal vedlægges som en eller flere DLL-filer. Den skal virke, efter at filerne er kopieres, dvs. ingen avanceret systemkonfiguration i Registry, ODBC, e.l.
Hvis det er DLL-filer, behøver der ikke at være en Delphi-komponent med til den. Jeg kalder bare metoderne direkte fra programmet.
Databasen skal gemmes i en enkelt fil på harddisken, eller en anden let tilgængelig måde, så jeg let kan lave backup-procedurer, e.l.
Det må gerne være open source, men det er ikke et krav.
Ingen multi-bruger understøttelse er nødvendig, da det udelukkende er til en bruger.
Den behøver ikke at understøtte relationsdatabaser. Den skal kun rumme en enkelt tabel, ligesom en Works-database.
Brug af AI afslører de svagheder, virksomheder allerede har opbygget gennem års cloud-transformation, nye SaaS-løsninger og fragmenterede sikkerhedssystemer.
Det lyder som en temmelig simpel database du vil lave.
Måske var det en ide helt at lade være med at benytte en database engine. Lav istedet en fil med records, som man gjorde i de gode gamle DOS dage. Så får du kunne en exe-fil med dit program og en fil med dine data. Der vil slet ingen opsætning være.
Du skal dog være opmærksom på at det kræver lidt mere programmering fra din side.
Der findes en udmærket database fra Turbopower (se www.turbopower.com) der hedder Flashfiler. Den fungerer som client/server, men kan konfigureres til enkeltbruger og compileres med i exe-filen. Den er iøvrigt lige kommet i en version 2 der understøtter sql.
Prøv Interbase 6 den er fra borland, kører godt, integeret med delphi, open source, nem at installere, ca. 20 liner delphi kode til auto install fra server eller disk, det er da nemt.
BDE er nem at benytte samme med Delphi. Det skal bare installeres. Når du skal lave en install-pakke til dit program. peger du bare ¨på BDE. Ellers kan den som pstric destribueres gratis sammen med dit program. http://www.borland.com/downloads/#bde
pstric & eagleeye >> Jeg vil IKKE have noget med BDE at gøre. Jeg har haft mange dårlige erfaringer med BDE, både installation og konfiguration. Den kræver også at man bruger InstallShield eller et andet autoriseret program til at installere programmet med.
pstric >> Jeg kender ikke JET. Det er måske en mulighed. Hvad med en link? Når jeg siger \'ingen avanceret konfiguration\' mener jeg næsten det samme som \'ingen konfiguration\'. Jeg laver selv installationsprogrammet, så den skal bare kopiere et par filer, og evt. lave et par registreringsnøgler, men det skal ikke være et stort projekt at installere det.
hkramer >> Kigger li\'e på den...
martinlind >> Har hørt om InterBase, men har ikke set på den endnu. Det gør jeg også li\'e...
microtec >> Det har jeg også tænkt på, men der er vel ikke grund til at opfinde den dybe tallerken igen? Jeg kan lige så godt bruge en database engine, da den sikkert bruger nogle bedre algoritmer, end dem jeg kan lave.
Jeg kigger på forslagene, så det kan godt tage lidt tid, inden jeg accepterer et svar.
Jeg vil gerne give delphidaner ret : BDE er noget hø, endda noget billigt hø !!!! Det skal distribueres sammen med dit program .. det skal instaleres og gøres ved på det, ig hvad værer det er ikke kombatibelt med noget som helst, end ikke sig selv !
Der findes et bedere alternativ kaldet topaz. På designtime ligner det de almindelige database komponenter, men i modsætning til BDE bliver det kompileret ind i dine exefiler, således der ikke skal distribueres ekstra programmer ....
Topaz er lavet af et firma der hedder Software Science (http://www.softsci.com/). hele den store komponent pakke kan erhverves for kun $99 du på deres hjemme side downloade en trail version gratis ...
Juubbiii ind i exe filen med database programmet. Når du så laver et nyt program som benytter en database, skal det med igen....flot der er nogle som tænker stor...
Lige en kommentar om mine (og mange andres) erfaringer med BDE. Selv om man benytter InstallShield, som jo supporterer installation af BDE, har jeg flere gange haft særdeles uheldige oplevelser. Problemet opstår, hvis der er andre applicationer installeret på computeren, som også benytter BDE. Jeg har flere gange været ude for at alias til disses databaser er forsvundet. Helt galt går det, hvis appliationerne benytter forskellige versioner at BDE.
Bang & Olufsen har netop sendet en beta-version af en MP3-player til test hos udvalget brugere (herunder mig :o). Der er flere der har oplevet at deres home-banking ikke længere fungerede efter installation af denne software, fordi den benytter nyeste version af BDE. For mit vedkommende var det mit bogføringsprogram, der midstede sit alias :o(
borrisholt>> BDE er noget hø ! Noget billigt hø endda ! (Citeret fra http://www.eksperten.dk/spm/42186, så det er nok rigtigt, at det ikke egner sig til arbejdsheste ;-)
JET er den engine, der kører Access og SVJV, følger den med Windows, så der bare skal laves ODBC til den. Jeg har aldrig programmeret på en computer, der ikke havde Office, så hvis der er nogen der ved, om den først installeres i forbindelse med Office, så skrig højt.
Jeg kunne desværre ikke lige finde et link, men der skal nok være noget på MS.
Derudover, hælder jeg mest til microtec\'s forslag. Hvis du kun skal bruge en enkelt tabel, så er en database engine da totalt overkill. Der er da intet som helst grundlag for at antage, at den har nogle effektive algoritmer til det du skal bruge.
pstric >> Du har så fulstendig ret i at en Database i mange forbindelser er overkill, ikke destomindere er det meget brugt ... Ude i den store verden findes der mennesker dik ikke kan skrive 4 linjers kode uden absolut at skulle gemme dem i den database bagefter .....
I mange tilfælde kan det ganske rigtigt bedere betalesig at lave et træ af en art og så lave noget persistens på det ....
pstric >> Enig i at en database engine hvis der er tale om en simpel database uden fler-bruger eller relationer. Mo ikke det delphidaner mener med \"den dybe tallerken\" er at han selv skal til at kode alle \"håndtag\" til f.eks. søgning.
eagleeye >> Ja, ODBC er en mulighed, som jeg ikke har overvejet. Hvilke databasedrivere følger med Windows?
microtec >> Jeg har også haft store problemer med installatino af BDE, især med versionskonflikter.
pstric >> OK, jeg prøver at finde noget om JET.
Grunden til at jeg gerne vil have en database engine, er fordi den sikkert har nogle meget bedre algoritmer, end dem jeg selv kan skrive. Når jeg skriver dette, tænker jeg mest på redigering af databasen, som f.eks. at slette en post. Jeg kan sagtens selv skrive en database kernel, men den vil sikkert ikke blive lige så god som dem der allerede findes.
Det jeg mener med den dybe tallerken er at der ikke er grund til at spilde tid på at skrive en database kernel, når der allerede findes masser af slagsen.
Det jeg mener er at : Glem din database ... I stedet burde du overveje fx. ar bruge et binært træ el. til at håndtere dine data .....
Så henter du dine data op fra disken engang og gemmer dinedata igen passende steder .... Hvis du ikke har brug for relationer etc. mellem forskellige tabeller, vil et træ så afgjort være værd at overveje ....
Hvis det absolut skal være så simpelt så du ikke \"må få glæde af db-faciliteter\", så kunne du jo overveje at lave det til en OOP-base det er temmelig enkelt i delphi, da man ret nemt kan benytte de indbygede streamming funktioner og så bare gemme det i en TClassList eller lign. det lavede jeg for et par år siden det kørete forbavsende godt, og kan laves meget dynamisk, jeg skulle bare udvide mit data-object så tilpassede programmet sig vha. RTTI.
delphidaner >> Lad mig illustere min pointe med et nemt eksempel : et array of integer
Las os antage dine data er integers, det kan være hvad som helst andet men for nemheds skyld lad mig antage integers.
fidusen er du kan selvfølgelig vælge at gemme disse integers i en tabel. Der i mod kunne du jo også vælge at stoppe dem i et array, som du så gemte på harddisken .... hvis bare du laver dit array STORT NOK så løser det problemet .....
Nu kan du hurtigt regne ud at jeg har ret mht. mit array, bevares det er ikke en særlig optimal løsning, men hold du nu dig til princippet, i det det er et meget tænkt eksempel....
jammen nu er det jo ikke sikkert du ønsker integers, men records i sredet fx.
type TUser = Record index : Integer; Name : ShortStirng; end;
så laver du dig bare et array [0..1000000] of TUser så er den i vinkel .... når så du skal gemme lordet laver du dig blot en file of Tuser og cykler hele arrayet i gennem og gemmer/loader det simple as that !
Det løser PRINCIPIELT dit problem .....
Kloge mennesker (og ja de findes rentfaktisk) har så opfundet forskellige ting til at gøre det her smartere .... Det findes forskellige træ stukturer der (strotset) ikke optager mere plads (RAM) end netop de data de inde holder, et eksemple her på et et binært træ, på http://borrisholt.com finder du en implemtering af et så. Der findes også mange andere og smartere trær. Det er meget hurtige at opdatere og søge i. Så skal du blot implemtere noget persistens i det træ du nu vælger også er den i vinkel !
Alternativt til trær, databaser og (dumme) arrays, er en TList. Du laver dig en klasse der er en nerarving af en Tlist som så sikere at kun din datatype (den klasse/record du har med dine data i) kan stoppes ind i listen, persistensen få du gratis ....
En Tlist er også meget hurtig at søge i idet den kan sorteres (meget let). så laver du blot en binærsøgning i den og så i løbet af 2 split nano har du dit svar.
og hvis du vælger et array for du en masse \"housekeeping\" som du kan slippe for med den løsning jeg beskev tidligere. Delphi 5 supporter rent faktisk Dynamiske array\'s så det der med at det skal være stort nok behøver du ikke tænke på mere.
Jeg synes helt klart at du skal vælge ADO til at styre dine databaser. Det kan let bruges til at læse alle forskellige database der er kompatible med OLEDB og/eller ODBC. Det er meget nemt at bruge og er fuldstændig lovligt at distribuere med sine programmer. ADO kan meget mere - f.eks. kan det programmeres til kunne forbinde næsten ALLE typer data (SMPT, filer m.v.).
bustermaniac >> Vil du indsætte et link? Jeg kender ikke rigtigt noget til OLE, COM, Active, ADO, og alle dem der.
eagleeye >> Fint nok! Det var også min første indskydelse at de var med, men jeg var ikke sikker. Har du noget kildekode til hvordan man kommunikerer med ODBC?
borrisholt >> OK, jeg er med.
martinlind >> Jeg overvejer endnu, men det bliver nok en DB via ODBC, for der er DB-kernerne allerede distribueret med Windows, og det kræver næsten ingen konfiguration.
Du kan benytte dig af almendelige SQL statements. Jeg har ikke lige noget Delphi kode, men jeg har da lavet lidt til ASP og C++.
Jeg kan evt. prøve at kikke lidt på det iaften, før har jeg ikke tid. Det er noge som jeg kan finde. Her lige hvad jeg faldt over:
Connecting from Delphi using the ODBC data source
ODBC connection from Delphi. Here is an example of connecting using the Tquery component. This example will also display the results of a sql statement.
? Drop a Tquery, a Tdatasource, and a Tdbgrid component on a Delphi form. ? Set the following properties for the Tquery component: 1) DatabaseName: Pick from the list the data source name you just created in ODBC Administrator. 2) SQL: Input the sql statement to be executed. For example: \"select * from table1\". 3) Active: Set to True to connect. And supply user name and password on connection. ? Set the following properties for the Tdatasource component: 1) Data Set: Set to the name of the Tquery component, or \"query1\" in this case. ? Set the following properties for the TDBGrid component: 1) Data Source: Set to the name of the Tdatasource component, or \"data source1\" in this case. ? Now you can see the returned results from select statement in the dbgrid area.
Hvis du kikker i beskrivelsen til en TQuery står der fakrtisk den kan benyttes sammen med windows stdart drivers ODBC (Access eks). De andre datacompunenter linker du jo til din TDataSource, så de er uafhængig af hvilken engine du benytter. Så det er ikke noget problem at benytte standart kompunenter.
Det var en mängd inlägg! Har du fått ditt svar? Hur många poster räknar du med? Vilken tid skall det ta att plocka upp posterna Skall de vara statiska eller dynamiska och det viktigaste Skall du köra rapporter ur databasen?
OK OK Det kanske var fler frågor än svar Men kvarstår att man man måste fråga mycket innan man kan ge ett korrekt svar!! Ursprungsfrågan är intressant. En Enkel, fri Db hantering är viktigt. Och vad står spörsmålet Nu!!?
lasp >> Jeg størrelsen af databasen vil langsomt vokse, og vil blive meget stor. Det må gerne være hurtigt, men det vigtigste er at det er stabilt. Det er fint nok I spørger, for som du selv siger så bliver svarene bedre af mange informationer.
Lige nu er jeg ret sikker på at jeg vælger at bruge ODBC til at håndtere databasen, men det kan godt være det er bedre at lave databasen selv, netop fordi den ikke kræver ret meget, som f.eks. relationer og SQL-understøttelse.
lasp >> Min drillede kommentar hentyder ikke til at man ikke må spørge. Jeg morede mig bare over at du afgav et \"Svar\", ikke en \"Kommentar\", og så stillede 5 spørgsmål :o)
delphidaner >> Person ligt ville jeg lave en \"database\" selv, med de krav/ønsker du har. Jeg kan ikke rigtig se formålet med at slæbe rundt med en \"Database engine\", som kan lave alt det forkromede, som du jo ikke skal bruge.
ODBC er sikkert et godt valg, men er I sikker på at ODBC-driveren til Access indstalleres uden Office-pakken i alle versioner af 32-bit Windows? Hvad med en gammel Win-95, er den også med der?
microtec >> Du har fat i noget. Mit program kommer til at køre på en hel del ældre maskiner, så det kan ikke udelukkes at der skulle være en Win95-version uden Access ODBC-driver.
Jeg tror jeg vælger at lave databasen selv. Hvis der er nogen, som har nogle kommentarer/meninger, så kan det nås endnu.
Nu har jeg lært en hel masse engines at kende. Så behøver jeg nok ikke at spørge jer eksperter en anden gang, hvor jeg har andre behov.
Ja det er dit valg. Men jeg forstår ikke helt dit valg. Du basere dit valg på et spørgsmål!! \"Er der ODBC i windows-95?\". Jeg ved det ikke 100% men jeg ser ingen grund til der ikke er det.
Jeg har nogle andre: Skal du lave udskrinver fra databasen i dit program? Skal man kunne søge i databasen fra dit program?
eagleeye >> Hvis en af windows-versionerne IKKE indeholder ODBC-driver til Access default, har du igen problemet med en kompliceret installation. Det var en af hoved-kravene i spørgsmålet.
Personlig, og det er min personlige mening, ser jeg ikke nogen grund til at benytte en avanceret \"Database engine\" når han ikke vil bruge f.eks. SQL, relationsdatabaser eller multi-bruger understøttelse.
microtec>> Du skriver selv \"ikke nogen grund til at benytte en avanceret \"Database engine\"\". Derfor forslå jeg ODBC. Man benytter bare en Access driver fra OBDC og så laver man database kommunication med SQL. Lettere kan det ikke bliver. Så får man samtidig et godt værktøj i hånden (SQL). Hvis man selv finder på det hele og laver sin egen database interface, går det glat før eller siden, det bliver tundt at arbejde med på længere sigt.
Tag en TQuery set datebasen driver til (ODBC Microsoft Access{*.mdb}),DitFilNavn.mdb). Du behøver ikke engang at oprette databasen i ODBC administration, det er kun nødvendigt hvis andre skal havde adgang til databasen.
Så kan man indsætte/slette/søge/sortre vha. nogle simple sql statements.
Ved at bruge ODBC får man en masse dejlige færdige \"håndtag\" at lege med.
Men, hvis ODBC-driveren til Access mangler i en af de gamle versioner af Windows har man et problem. Ikke bare er det besværligt at installere den, man løber også ind i et licens-problem. Microsoft har alle rettighederne til Access ODBC-driveren, så man kan ikke bare inkludere den i ens eget installations-job.
Ja der er et problem. Jeg har kikket lidt ved MS for at undersøge det. Der ligger nogle ODBC driver på deres sider. Nej man løber ikke ind i licens problemmer ved ODBC. Hvis du installere Access Programmet uden tilladelse, ja så har du et problem. ODBC driverne er en del at windows så der er ikke noget at includere i installation filen..... Som sagt før kan jeg ikke se hvorfor access driveren skulle være udeladt fra eks.vis windows 95.
Ring til MS og spøg om ODBC access driveren er med i Windows 95. For at opfinde sine egne drivere, lyder i mine øre lidt for vildt.
Du må heller ikke distribuere dele af Windows. Det er det du accepterer under installationen af Windows ;o)
Men jeg syntes da det kunne være interessant at vide om man bare kan gå ud fra Access-driveren altid er der. Jeg har ikke kunnet finde noget der af- eller be-kræfter. Desværre læste jeg et sted at der kunne være problemer med forskellige versioner af driveren. Altså, vis forskellige Applicationer skulle bruge forskellige versioner af ODBC. Altså lidt det samme som jeg har oplevet med BDE.
>Forøvrigt mener jeg ikke at delphidaner skal \"opfinde sine egne drivere\". Det vil vist være i overkandten at kalde et simpelt program til håndtering af records i en fil for en driver ;o)
Jeps en del af windows. Netop derfor skal det ikke distrubueres med programmet, det er jo en del af windows....
Jeg har engang selv lavet et program som skulle gemme nogle record i en fil. Læse/Skrive er ikke det helt store problem. Hvis du vil lave noget avanceret søgning bliver det døden... Dels er det ikke nemt at vedligeholde, hvis du vil udvide med felter i recorden skal der laves meget om.
eagleeye >> Du må mene \"muligvis\" en del af Windows :o) Hverken du eller jeg har kunnet be- eller af-kræfte om ODBC-driverne til Access findes i alle versioner Siger kun HVIS der er en version, hvor driveren ikke er, så har man et problem. Man kan ikke bare lægge den med i instalationsjobbet.
Jeg tror vores holdninger er klare nok. Lad os lade delphidaner selv træffe afgørelsen.
Jeg tror at jeg vælger at lave min egen databasehåndtering i programmet, først og fremmest fordi jeg selv har total kontrol over hvad der sker. Når jeg ved hvordan posterne lagres, så kan jeg også lave data recovery, osv. Når det er sådan en simpel database som den jeg har brug for i dette tilfælde, så er der ikke e store problemer i at lave den selv. Jeg kan ikke se, hvorfor det skulle være så svært at søge i databasen.
Til gengæld skal du have lidt point eagleeye fordi du har hjulpet mig med at bruge ODBC, som egentlig er en glimrende database interface. På nuværende tidspunkt er jeg i stand til at lave en SystemDNS til Access i Delphi(http://www.delphi3000.com/articles/article_1752.asp), og kommunikere med den. Hvis jeg på et andet tidspunkt skal bruge noget mere avanceret er jeg ikke i tvivl om at jeg skal bruge ODBC. Det med om Access-driveren er med eller ej, kan man vel spørge Microsoft om hvis det bliver aktuelt. De har sikkert en eller anden SDK support e-mail-adresse, eller lignende et eller andet sted på deres hjemmeside.
Hvorfor afviste du brugen af flashfiler fra TurboPower ? Den compileres med i exe-filen, er drønhurtig og nem at bruge. Der skal ikke distribueres extra dll-er eller noget sådant med.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
