12. januar 2006 - 11:38Der er
21 kommentarer og 1 løsning
Miljøvariabler til SQLDatabase
Hej folkens.
Jeg er ved at lave et java-program, som skal bruge en lokal SQL database, og er blevet anbefalet at benytte Borland Interbase, men jeg kan ikke finde ud af hvordan jeg opsætter en ODBC forbindelse til databasen uden at selve Borland Interbase programmet er installeret, og det er jo ikke meningen at det skal være hos modtageren. Er der nogen der kan give en forklaring på hvordan det gøres - evt. via miljøvariabler!??
Tænkte på om det ikke lige så godt kunne have været en MSAccess database - det giver vel det samme?? - er det nødvendigt at have access installeret da??
Enten skal du bruger Interbase og Borlands JDBC drivere.
Eller du skal opdatere til Firebird med nyeste JDBC driver til denne.
Access er ikke noget godt valg da der ikke er en JDBC driver til den, men hvis du er tiltrukket af at der ikke skal installeres end database server på systemet, så prøv og kig på HSQLDB !
Nu har jeg ikke prøvet med HSQLDB endnu - serveren er lige nede for vedligeholdelse...
Angående den anden mulighed - prob. er at jeg står med en SQL database med data i nu, som skal flyttes over i den nye database... - er det muligt med den omtalte db4o ?? - eller kan det blive et problem?
Hej Arne... jeg har fået det hele til at virke mht. det HSQLDB - fik endelig tid til det... Men nu står jeg så med et problem angående den .script fil som ligger med min database.. - den vil jeg gerne have skjult for brugeren, eller krypteret på en eller andet måde, så brugeren ihvertfald ikke kan tilgå og læse den.. kan det lade sig gøre ??
Jeg har brugt det HSQLDB som du henviste til - det fungerer også ganske fint, men det virker kun hvis jeg ligger '.script' filen med i mappen. Den fil hvor alle mine SQL koder står skrevet - og dem er jeg ked af at give videre.
En lokal database vil brugeren altid kunne få adgang til på en eller anden måde, du kan sikkert gøre det mere besværligt men er det det værd? Hvis du ikke stoler på brugeren så skulle du måske overveje noget andet. hsqldb kan bruges clint-server. http://www.hsqldb.org/doc/guide/ch01.html#N1013D
default kører HSQLDB i en mode hvor den ikke gemmer en rigtig database men et script med alle de SQL sætninger som er nødvendige for at recreate databasen
Ååååh... det er så guld det der !! Det var netop det jeg mente. Ved godt det er svært at skjule selve indholdet og mine SQL-filer. Det er absolut heller ikke "proffessionelle aftagere", som skal benytte det her program, men ville da være ked af at have alle SQL sætninger til at ligge så man frit kunne kopiere dem direkte over. - og det ser lidt bedre ud på den her "cached" måde.
Nu er jeg kommet fra ferie og har hørt at det sql-system jeg lavede med det HSQLDB har en lille mangel.
Har opdaget, at databasen kun gemmer data når man kalder "Shutdown" på databasen, men jeg vil gerne at den gemmer alle data også selvom den ikke lukkes korrekt. Eksempelvis hvis computeren går ned, så vil jeg gerne, at man kan åbne programmet igen og "gendanne" de data som blev indtastet inden systemet gik ned. Kan det lade sig gøre på nogen måde?? - og hvordan ?? Håber du kan hjælpe.
jeg vil lige proeve at studere HSQLDB docs omkring det
(jeg antager at du allerede bruger catch til at faa lukket paent ned hvis applikationen crasher, saaledes at det kun er system crash vi skal haandtere)
All databases running in different modes can be closed with the SHUTDOWN command, issued as an SQL query. From version 1.7.2, in-process databases are no longer closed when the last connection to the database is explicitly closed via JDBC, a SHUTDOWN is required. In 1.8.0, a connection property, shutdown=true, can be specified on the first connection to the database (the connection that opens the database) to force a shutdown when the last connection closes.
The test.properties still containes 'modified=yes'. *
The test.script contains a snapshot of the database at the last checkpoint and is OK. *
The test.data file may be corrupt because the cache in memory was not written out completely. *
The test.backup file contains a snapshot of test.data that corresponds to test.script. *
The test.log file contain all information to re-do all changes since the snanapshot. As a result of abnormal termination, this file may be partially corrupt.
...
Repair
The current test.data file is corrupt, but with the old test.data (from the test.backup file and test.script) and the current test.log, the database is made up-to-date. The database engine takes these steps:
Procedure C.3. Database Repair
1.
Restore the old test.data file from the backup (uncompress the test.backup and overwrite test.data). 2.
Execute all commands in the test.script file. 3.
Execute all commands in the test.log file. If due to corruption, an exception is thrown, the rest of the lines of command in the test.log file are ignored. 4.
Close the database correctly (including a backup).
Jeg er ikke helt sikker på jeg forstår hvori backup'en ligger. Jeg har prøvet at kigge på det, men det lader ikke helt til at det virker alligevel. Eller det virker cirka hver 10. gang, men det er ikke helt til at gennemskue hvad der er galt.
Jeg har ikke nogen .data fil... - skal den bruges ?? Og hvor stammer den fra? Kan ikke gennemskue om man eventuelt kan ændre noget i properties filen... - synes det virker fornuftigt i dokumentationen, men det virker ikke helt i praksis.!
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.
