Paradox-Datenbank komprimieren?
-
Hallo!
In der Datenbankoberfläche des C++ Builders gibt es die Funktion "Umstrukturieren" mit der Unterfunktion "Komprimieren".Mit welcher Funktion kann ich genau diese Schritte in mein Programm einbauen?
Für eine kurze Hilfe wäre ich dankbar.
Gruß
Maik
-
Zum Umstrukturieren kann man entweder direkt SQL verwenden (ALTER TABLE), oder die Funktion DbiDoRestructure() verwenden. Zum Komprimieren der Tabelle wirst Du DbiDoRestructure verwenden müssen. Näheres dazu gibt es im BCB unter: Hilfe->C++Builder-Tools, dann nach der Funktion suchen.
Und wie immer der Hinweis: Paradox und die BDE sind tot! Diese werden nicht mehr gepflegt oder weiter entwickelt. Im Einsatz verursachen sie mittlerweile eine Menge Probleme.
Zum Ausprobieren und Testen ist es ganz ok, aber für mehr sollte man diese nicht mehr verwenden. Ebenfalls Finger weg von TTable.
-
@Joe_M.
warum finger weg von TTable? kannste mir mal ein paar gründe nennen (bin nicht mehr so auf dem neusten stand was db-zeugs angeht)? warum sollte man die bde nicht mehr verwenden? nur weil sie nicht weiter entwickelt wird? (passiert doch mit dem windows-kernel auch nicht. ;)) für kleine db-anwendung ist die doch sicher durchaus noch zu gebrauchen und auch paradox als db-file?
@mailmueller
schau mal unter http://www.bdesupport.com. dort gibts tools und source-code um paradox tabellen und zu komprimieren, zu reparieren und ne menge mehr.
-
Die BDE und Paradox (und auch dBase) haben z.B. massive Probleme mit den OpLocks unter Windows. Diesen müssen zwangsläufig deaktiviert werden.
Mein 'Lieblingsfehler': Wenn der freie Festplattenspeicher auf der HDD % (modulo) 4 GB == 0 ist, kann in die Tabellen nichts mehr geschrieben werden.
Es treten regelmäßig Fehler auf, die nur durch Feintuning an den Grundeinstellungen der BDE behoben werden können. Gerne gibt es auch mal einen defekten Index, was die Tabelle unbrauchbar macht.
Das Problem ist, dass man nicht abschätzen kann, wann welcher Fehler unter welchen Umständen auftritt.Wenn man noch irgendwo einen alten Novell Server rumstehen hat, kann man Paradox durchaus noch verwenden. Auf NT4 läuft es auch noch recht brauchbar. Unter Windows 2000 und XP muß man regelmäßig mit Fehlern rechnen, die man auf den ersten Blick nicht nachvollziehen kann. Zu Windows 2003 kann ich nichts sagen.
Ich hab noch ein paar ältere Programme, die lokale Paradox-Programme verwenden (unser alter DB-Server war mit dem 'Tagesgeschäft' schon sehr ausgelastet, so dass ich für komplexe Abfragen die Rohdaten in lokale Paradoxdateien geschrieben habe...). Ich bin über jeden Tag froh, wo das Telefon nicht klingelt...
Die Original-TTable-Komponente ist prima, keine Frage. Da man aber die BDE nicht mehr verwendet, kann man auch TTable nicht mehr verwenden.
Alle anderen TxxxTable-Komponenten (z.B. TADOTable) sind kaum mehr als Marketinggags. Ihre primäre Existenzberechtigung ist, dass man damit 'schnell' eine BDE-Anwendung auf z.B. ADO umstellen kann. Theoretisch. Bei kleinen Projekten geht das auch, aber ich hab noch kein größeres Projekt gesehen, dass sich wirklich damit umstellen ließ. Schätzungsweise 50% der TTable-Komponenten muß man direkt durch Datasets ersetzen, da die TxxxTable-Komponenten bestimmte Funktionen des originalen TTables nicht unterstützen, oder diese schlicht und ergreifend nicht, oder zumindest nicht wie bisher gewohnt funktionieren. Leider muß man dafür die gesamte Anwendung intensiv testen, um zB feststellen zu können, dass der Filter von TADOTable andere Ergebnisse liefern kann, als der von TTable... Die Tücke liegt hier im Detail.Unterm Strich gesehenm, ist es die ganze Mühe nicht wert. Wenn man in seinen Programmen regelmäßig (lokale) Datenbanken verwendet, würde ich Firebird / Firebird embedden empfehlen. Dieses ist kostenlos, unter Windows und Linux verfügbar. Es gibt gute kostenlose Komponentensammlungen.
Wobei ich mittlerweile sogar von ADO als Zugriffskomponenten abrate. Native Komponenten bieten mehr Flexibilität und teilweise deutlich mehr Performance.
-
@Joe_M:
Du schreibst was von Nativekomponenten statt der im Builder integrierten ADO etc., kannst Du mir eine konkrete Alternative empfehlen?
Gruß
Maik
-
passiert doch mit dem windows-kernel auch nicht
Aha, Windows 3.1 -> 95 -> 98->2000 -> XP -> Vista?? -> 64 Bit
Das sind keine Weiterentwicklungen ??
Alternative wäre noch MYSQL. In dem hoffentlich bald zu erwartenden C++Builder 2006 soll eine entsprechende Unterstützung dabei sein.
-
Native Komponenten sind Komponenten, die für eine bestimmte Datenbank entwickelt wurden. Diese unterstützen dann meist auch alle Besonderheiten der DB und sind um Klassen schneller, als der Zugriffe über die Zwischenschicht mit z.B. ADO.
Ob es für Paradox etwas gibt, weiß ich nicht. Paradox verwende ich in neuen Projekten aber auch nicht mehr (solltest Du auch nicht).
Für die Firebird-DB gibt es IBOjects, FIBPlus, ZEOS, IBX. Für den Anfang kann man auch erst mal mit den dem BCB (ab Prof.) beiliegenden IB-Komponenten arbeiten.
-
zumindest fuer die alten windows-versionen scheint das schon gültig:
The 32-bit Windows API on DOS-Windows 95/98/ME is built on top of the 16-bit Windows kernel. Much of the functionality of the 32-bit API DLLs (kernel32.dll, user32.dll, gdi32.dll, advapi32.dll, and so forth) is provided by thunking from 32-bit to 16-bit and calling into the 16-bit Windows kernel, grabbing a global mutual exclusion semaphore known as "Win16Mutex" (that prevents multiple threads from executing in the 16-bit Windows kernel concurrently) for the duration.
und den fand ich schon immer gut:
Windoze95: <win-doz-nin-te-fiv> 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition.
Linux: Because rebooting is for adding hardware.