Paradox auf Mehrplatzsystem, was muss ich beachten?
Markus Wagner
Ich hab ein Delphi-Programm mit Paradox-Datenbank und möchte das
Programm von mehreren Rechnern gleichzeitig nutzen. Was ist speziell zu
beachten?
Wie kann ich einen Datensatz sperren?
Gibts über dieses umfangreich scheinende Thema Tutorials?
Danke für Euro Hilfe
mfg
--
Markus Wagner
E-mail: markus...@gmx.at
Hobby: PHP, 747 Jumbo-Jet, Pontiac
Fingerprint: B208 0ADF 4DC8 18EF E36E 0FFF 370E 7032 5E2B 44AA
Ralf Mimoun
"Markus Wagner" <markus...@gmx.at> schrieb:
> Hallo
>
> Ich hab ein Delphi-Programm mit Paradox-Datenbank und möchte das
> Programm von mehreren Rechnern gleichzeitig nutzen. Was ist speziell zu
> beachten?
Net Dir muß überall gleich sein. Wenns ein Windows NT-Server ist, bekommst
Du höchstwahrscheinlich Probleme. Wenn Du die Wahl hast und nicht Mannmonate
in den Support einer nie richtig laufenden Anwendung stecken willst, nimm
irgendetwas anderes.
> Wie kann ich einen Datensatz sperren?
Table.Edit.
> Gibts über dieses umfangreich scheinende Thema Tutorials?
Schau Dich bei community.borland.com um.
Bye, Ralf
Markus Wagner
> Du höchstwahrscheinlich Probleme. Wenn Du die Wahl hast und nicht Mannmonate
> in den Support einer nie richtig laufenden Anwendung stecken willst, nimm
> irgendetwas anderes.
Was für Probleme könnten das sein?
Was für Alternativen hab ich? Ein SQL-Server, mysql?
Ralf Mimoun
"Markus Wagner" <markus...@gmx.at> schrieb:
> > Net Dir muß überall gleich sein. Wenns ein Windows NT-Server ist,
bekommst
> > Du höchstwahrscheinlich Probleme. Wenn Du die Wahl hast und nicht
Mannmonate
> > in den Support einer nie richtig laufenden Anwendung stecken willst,
nimm
> > irgendetwas anderes.
>
> Was für Probleme könnten das sein?
Zerschossene Indizes, zerschossene Tabellen, schwer (oder nicht) zu
reparierende Tabellen, Fehler in der Anwendung...
> Was für Alternativen hab ich? Ein SQL-Server, mysql?
DBISAM, ADS; mySQL, MS SQL, Oracle, Interbase/Firebird, DB/2 und so weiter.
Kommt drauf an, wieviel Geld Du ausgeben kannst, wieviel Zeit Du zur
Einarbeitung hast, ob Du einen Server voraussetzen kannst, welches
Betriebssystem auf dem Server läuft, wie aufwändig die Installation später
sein darf etc.pp.
Bye, Ralf
Marian Aldenhövel
> Ich hab ein Delphi-Programm mit Paradox-Datenbank und möchte das
> Programm von mehreren Rechnern gleichzeitig nutzen. Was ist speziell zu
> beachten?
Neben den eher praxisorientierten Tips möchte ich Dir dringend raten
stattdessen lieber auf eine richtige Datenbank zu setzen.
Je nachdem ob Du bisher _sehr_ auf Desktopdatenbanken spezialisiert
gearbeitet hast oder das Programm wenigstens so tut als wäre Paradox eine
Datenbank, ist der Aufwand für die Umstellung von Paradox-Einzelplatz auf
Paradox-Mehrplatz dem von Paradox-Einzelplatz auf <DBMS>-Mehrplatz durchaus
vergleichbar.
Nur kommt bei letzterem mit höherer Wahrscheinlichkeit ein brauchbares
Programm raus.
Ciao, MM
--
Marian Aldenhövel, Hainstraße 8, 53121 Bonn
Mein Flug um die Welt (aktuelle Position: Lima)
http://www.marian-aldenhoevel.de/ATW
Markus Wagner
> DBISAM, ADS; mySQL, MS SQL, Oracle, Interbase/Firebird, DB/2 und so weiter.
> Kommt drauf an, wieviel Geld Du ausgeben kannst, wieviel Zeit Du zur
> Einarbeitung hast, ob Du einen Server voraussetzen kannst, welches
> Betriebssystem auf dem Server läuft, wie aufwändig die Installation später
> sein darf etc.pp.
Rahmenbedingungen:
Die Installation soll nicht komplizierter sein als eine normale
Installshield-Installation. Also setup.exe ausführen und zusätzlich
öfters auf "Weiter"-klicken ist das was der Kunde maximal versteht.
Netzwerklaufwerk anlegen geht auch noch.
Betriebssystem: 95,98,NT,2k,XP
Benutzerzahl: meist 1 bis max 5
Was für mich wichtig ist: Muss ich, wenn ich eine andere Datenbank
verwende, viel am Source ändern? Momentan wird die Paradox-DB mittels
BDE angesprochen. Verwende TTable, TDataSource, TQuery.
mfg
Ralf Mimoun
"Markus Wagner" <markus...@gmx.at> schrieb:
> Ralf Mimoun wrote:
> > DBISAM, ADS; mySQL, MS SQL, Oracle, Interbase/Firebird, DB/2 und so
weiter.
> > Kommt drauf an, wieviel Geld Du ausgeben kannst, wieviel Zeit Du zur
> > Einarbeitung hast, ob Du einen Server voraussetzen kannst, welches
> > Betriebssystem auf dem Server läuft, wie aufwändig die Installation
später
> > sein darf etc.pp.
>
> Rahmenbedingungen:
>
> Die Installation soll nicht komplizierter sein als eine normale
> Installshield-Installation. Also setup.exe ausführen und zusätzlich
> öfters auf "Weiter"-klicken ist das was der Kunde maximal versteht.
> Netzwerklaufwerk anlegen geht auch noch.
>
> Betriebssystem: 95,98,NT,2k,XP
> Benutzerzahl: meist 1 bis max 5
>
> Was für mich wichtig ist: Muss ich, wenn ich eine andere Datenbank
> verwende, viel am Source ändern? Momentan wird die Paradox-DB mittels
> BDE angesprochen. Verwende TTable, TDataSource, TQuery.
Meine Standard-Antwort: DBISAM. Du mußt TTable durch TDBISAMTable ersetzen
(Gleiches für TQuery und TDatabase, TDatasource bleibt natürlich erhalten).
Das geschieht am einfachsten per Search&Replace in der DFM-Datei. Dann noch
ein, zwei Zeilen im TDBISAMDatabase.OnConnect (DB- und Temp-Verzeichnis
zuweisen), das wars im Groben. Mit ein wenig Übung ist eine mittelgroße
Anwendung in 2-4 Stunden auf DBISAM umgestellt.
Installiert werden muß exakt gar nichts. Keine DLL, kein Server (gibts aber,
wenn man möchte), kein gar nichts. Absolut alles liegt im Sourcecode vor.
Und ob man nun Queries oder Tables benutzt, ist ziemlich egal.
Bye, Ralf
Thomas Malkus
"Ralf Mimoun" <r.mi...@rapid-software.de> wrote:
>Installiert werden muß exakt gar nichts. Keine DLL, kein Server
>(gibts aber, wenn man möchte), kein gar nichts. Absolut alles
>liegt im Sourcecode vor. Und ob man nun Queries oder Tables
>benutzt, ist ziemlich egal.
Wobei man die Queries eventuell etwas überarbeiten muß, wie
das bei meinem kleinen Problem der Fall war. Unter Paradox
lief das ja noch schnell. Aber selbst das ist kein Problem
und die Datenbank kann man mit dem Tool von DBISAM gleich
komplett übernehmen lassen.
Für eine schnelle Installation bei unbedarften Usern zu empfehlen.
Ich würde dann nur noch den Installshield in die Tonne kloppen und
dafür Inno-Setup nehmen.
73 de Tom
--
DL7BJ DOK I19 JO43PC Uptime 1d 21h 21m
27356 Rotenburg Linux? Nö, W2k!
Christian NineBerry Schwarz
Thomas Malkus schrieb:
> Wobei man die Queries eventuell etwas überarbeiten muß, wie
> das bei meinem kleinen Problem der Fall war. Unter Paradox
> lief das ja noch schnell. Aber selbst das ist kein Problem
> und die Datenbank kann man mit dem Tool von DBISAM gleich
> komplett übernehmen lassen.
Wie ist denn die Performance bei lokalen SQL-Abfragen bei DBISAM im
Vergleich zu Paradox?
Wie sieht es mit der Blob-Problematik bei DBISAM aus? Ich spreche hier
nicht von den berühmten Blob-Fehlern in Paradox, sondern der
Möglichkeit bei SQL-Abfragen Case-Insensitive in Blob-Feldern suchen zu
können.
Traubensaft gibt Traubenkraft
Christian "NineBerry" Schwarz
--
Guido Westerwelle hat ein Wohnmobil.
Peter Struck fährt mit dem Motorrad.
Jürgen Trittin kommt auf seinem Fahrrad.
Und Angela Merkel nimmt den Bus.
Ralf Mimoun
"Christian NineBerry Schwarz" <Christia...@nineberry.de> schrieb:
...
> Wie ist denn die Performance bei lokalen SQL-Abfragen bei DBISAM im
> Vergleich zu Paradox?
Kommt drauf an. Bei brute force-Abfragen (also große Datenmengen, es kann
kein Index genutzt werden) ist die BDE schneller. Ansonsten hat sie meistens
kaum eine Chance. Schon weil die SQL-Unterstützung bon DBISAM einfach
unendlich besser ist.
> Wie sieht es mit der Blob-Problematik bei DBISAM aus? Ich spreche hier
> nicht von den berühmten Blob-Fehlern in Paradox, sondern der
> Möglichkeit bei SQL-Abfragen Case-Insensitive in Blob-Feldern suchen zu
> können.
Ein reines BLOB ist ein Feld mit einem Inhalt, dessen Form(at) nicht
definiert ist. Darin zu suchen ist eher sinnfrei - die Engine kann nicht
davon ausgehen, irgendwas Lesbares zu finden. So kann da ja auch ein #0
gefunden werden - und was dann? Aber es geht - mit der #0-Einschränkung.
Einfach ein SELECT * FROM Tabelle WHERE UPPER(CAST(Blobfeld AS
BLOB(0,1)))="%SUCHTEXT%" und gut ist. Das BLOB(0,1) ist was häßlich (damit
ist der Blob-Typ MEMO gemeint), aber Elevate wird da bald auch "richtige"
Bezeichner definieren.
In Memos kann gesucht werden, per UPPER() wird die Sache, wie man oben
sieht, dann case insensitive. Richtig lustig wirds mit TEXTSEARCH und
TEXTOCCURS: damit kann nach Worten gesucht werden. DBISAM unterstützt das,
indem Full Text-Indizes definiert werden können, in der Feldinhalte nach
Worten aufgedröselt werden. Dann geht ein SELECT rasend schnell.
Bye, Ralf
Thomas Malkus
Christian NineBerry Schwarz <Christia...@nineberry.de> wrote:
>Wie ist denn die Performance bei lokalen SQL-Abfragen bei DBISAM
>im Vergleich zu Paradox?
Ich habe da keine Tests gemacht, ich hatte nur ein Problem mit
2 Queries. Ich hatte mit dem Programm beim Start alle Abfragen
aktiviert (wie im Handbuch von DBISAM beschrieben) und durch
2 Queries verzögerte sich der Programmstart ganz erheblich.
Ralf hatte mir bestätigt, dass das auch so richtig ist. Ich habe
dann als Lösung die Queries beim Programmstart herausgenommen und
aktiviere die nun erst bei Bedarf (sind beide nur für einen Report).
Seltsamerweise geht es jetzt auch zügig. Das war die erste Anwendung,
die ich einfach mal auf die Schnelle von Paradox auf DBISAM
umgestellt habe.
Ansonsten habe ich noch nicht genug mit DBISAM gemacht, um hier
eine Aussage zu treffen, aber subjektiv gesehen kann ich da keinen
Unterschied feststellen.
>Wie sieht es mit der Blob-Problematik bei DBISAM aus? Ich spreche
>hier nicht von den berühmten Blob-Fehlern in Paradox, sondern der
>Möglichkeit bei SQL-Abfragen Case-Insensitive in Blob-Feldern
>suchen zu können.
Keine Ahnung, ich brauche für meine Messwerte keine Blob-Felder.
Aber Ralf kann da sicherlich bessere Aussagen zu treffen.
Was ich aber definitiv sagen kann, wo jetzt die ersten Versionen
ausgeliefert sind, es gibt keine Probleme auf der Kundenseite
mehr, es läuft einfach ;-).
73 de Tom
--
DL7BJ DOK I19 JO43PC Uptime 2d 2h 35m
Markus Wagner
> Moin!
>
> Meine Standard-Antwort: DBISAM. Du mußt TTable durch TDBISAMTable ersetzen
> (Gleiches für TQuery und TDatabase, TDatasource bleibt natürlich erhalten).
> Das geschieht am einfachsten per Search&Replace in der DFM-Datei. Dann noch
> ein, zwei Zeilen im TDBISAMDatabase.OnConnect (DB- und Temp-Verzeichnis
> zuweisen), das wars im Groben. Mit ein wenig Übung ist eine mittelgroße
> Anwendung in 2-4 Stunden auf DBISAM umgestellt.
>
> Installiert werden muß exakt gar nichts. Keine DLL, kein Server (gibts aber,
> wenn man möchte), kein gar nichts. Absolut alles liegt im Sourcecode vor.
> Und ob man nun Queries oder Tables benutzt, ist ziemlich egal.
>
> Bye, Ralf
DBISAM macht das gleiche wie Paradox nur ohne BDE und ist besser für ein
Mehrplatzsystem besser geeignet.
Wenn ich einen SQL-Server (mysql, MSSQL) verwenden möchte, gibts keine
andere Möglichkeit mein Programm komplett auf SQL-Befehle umzuschreiben.
Richtig?
Ralf Mimoun
"Markus Wagner" <markus...@gmx.at> schrieb:
...
> DBISAM macht das gleiche wie Paradox nur ohne BDE und ist besser für ein
> Mehrplatzsystem besser geeignet.
Mehr oder minder. Es kann mehr, es ist sauberer aufgebaut, und man kann auch
ein sauberes C/S-System bauen.
> Wenn ich einen SQL-Server (mysql, MSSQL) verwenden möchte, gibts keine
> andere Möglichkeit mein Programm komplett auf SQL-Befehle umzuschreiben.
> Richtig?
Nein. Man kann mit Tables arbeiten, aber das ist nicht zu empfehlen. Die
Umsetzung von SQL-Statements und resultierenden Dagenmengen auf das
Table-Konzept kostet jede Menge zeit und Speicher.
Bye, Ralf
Thomas G. Liesner
> DBISAM macht das gleiche wie Paradox nur ohne BDE und ist besser für ein
> Mehrplatzsystem besser geeignet.
Welche Datenbankformate unterstützt DBISAM eigentlich? Bei der BDE habe
ich Paradox DBase vorgezogen, da dort im Normalfall wenigstens der
Primärschlüssel problemlos funktionierte...
So long,
Thomas G. Liesner
Ralf Mimoun
"Thomas G. Liesner" <t...@gmx.de> schrieb:
...
> Welche Datenbankformate unterstützt DBISAM eigentlich?
DBISAM. Hier die Spezifikationen:
------------------------------------
Capacity Details
# of Blob Fields Per Table Maximum number of blob fields per table is 64.
# of Decimal Places for BCD Fields Maximum number of decimals places for BCD
fields is 4.
# of Fields Maximum number of fields in a table is 1024.
# of Fields in Index Key Maximum number of fields that can be present in an
index key is 16.
# of Indexes Maximum number of primary indexes is 1. Maximum number of
secondary indexes is 30.
# of Open Blobs Per Table Maximum number of open blobs per table is 64. You
should never have to worry about this figure because the DBISAM data access
components handle opening and closing blobs automatically.
# of Open Tables Only limited by available memory and open file handles.
DBISAM uses a maximum of 3 file handles per table: one for the table, one
for the index file, and one for the blob file (if there are blob fields
present in the table).
# of Records Per Table Maximum number of records that can be added to a
table is 200 million under Windows 95/98/ME and 1 billion under Windows
NT/2000.
# of Records in a Transaction Only limited by available memory.
Size Of Tables, Index Files, and BLOB Files The maximum size of a table
(.DAT), index file (.IDX), or BLOB file (.BLB) is 4,000,000,000 under
Windows 95/98/ME and 128,000,000,000 bytes under Windows NT/2000.
Size of Blob Blocks The minimum blob block size is 64 bytes and the maximum
blob block size is 64k.
Size of Blob Data Maximum length of blob data in a blob field is only
limited by available memory.
Size of In-Memory Tables Maximum length of an in-memory table, index file,
or blob file is only limited by available memory.
Size of Index Keys Maximum length of an index key is 512 bytes. Please note
that the index key length is not an exact sum of the length of the fields
present in the index key. The proper way to calculate the index key length
is as follows:
. For primary indexes the calculation is ((Sum of field sizes) + Number
of Fields in Index Key
. For secondary indexes the calculation is ((Sum of field sizes) + Number
of Fields in Index Key + 4
The extra bytes for the number of fields are the NULL flags used to order
the index keys properly based upon whether they are NULL or not.
The additional four bytes for secondary indexes is used to store a unique
record ID which is essential for proper bookmark support.
Please note that the length of string fields in index keys includes the null
terminator character. For example, if a string field has a length of 15
then it's length in an index key would be 16.
Size of Records Maximum record size is 64k.
Size of String Fields Maximum length of a string field is 250 bytes. Please
note that this figure does not include a NULL terminator character. The
NULL terminator character is handled internally.
------------------------------------
Bye, Ralf
Thomas G. Liesner
>> Welche Datenbankformate unterstützt DBISAM eigentlich?
> DBISAM. Hier die Spezifikationen:
Die Frage war anders gemeint: Hat er nur ein eigenes DB-Format oder
unterstützt er noch andere Fremdformate wie zumindest DBASE?
Ralf Mimoun
"Thomas G. Liesner" <t...@gmx.de> schrieb:
DBISAM unterstützt DBISAM. Nichts anderes. Eine Konvertierung ist, dank
entsprechendem Tool, in Nullkommanichts gegessen, wer jedoch die Daten in
einem anderen Format benötigt, muß etwas anderes einsetzen.
Bye, Ralf
Thomas G. Liesner
> DBISAM unterstützt DBISAM. Nichts anderes. Eine Konvertierung ist, dank
> entsprechendem Tool, in Nullkommanichts gegessen, wer jedoch die Daten in
> einem anderen Format benötigt, muß etwas anderes einsetzen.
d.h. für eine DBase-Export-Möglichkeit in einem DBISAM-Programm muß man
eine weitere DBase-Spezial-Komponente bzw. die BDE nutzen? Ok, damit
kann man durchaus leben.
Thomas Malkus
Na, ich weiß nicht. Ich setze DBISAM ein, damit ich gerade die
BDE nicht verwenden muss. Nur für einen dBase Export nun die
BDE einzubauen kommt überhaupt nicht in Frage. Export als CSV
Datei reicht doch meist auch aus, dass kann man meistens auch
in anderen Programmen wieder importieren.
73 de Tom
--
DL7BJ DOK I19 JO43PC Uptime 3d 13h 46m
Ralf Mimoun
"Thomas G. Liesner" <t...@gmx.de> schrieb im Newsbeitrag
news:aaqvd1.3...@news.tglsoft.de...
Jep, braucht man. Ich hab irgendwo noch eine Uralt-Unit zur Erzeugung von
dbase-Dateien - ohne Komponente, einfach nur ein paar Funktionen. Das würde
wohl ausreichen.
Bye, Ralf
Thomas G. Liesner
> Jep, braucht man. Ich hab irgendwo noch eine Uralt-Unit zur Erzeugung von
> dbase-Dateien - ohne Komponente, einfach nur ein paar Funktionen. Das würde
> wohl ausreichen.
Falls man natürlich auch Importe unterstützen will, braucht man eine
größere Lösung. Akut ist das jetzt eh nicht für mich, aber sollte ich
doch mal was in der Richtung brauchen, sind mir die Möglichkeiten jetzt
schon deutlich klarer geworden.