Database Reference
In-Depth Information
alle neu erstellten Formulare in einer ACCESS-Datei irreparabel
zerstört worden sind, kommt richtig Stimmung auf.
Daher meine Tipps für Programmentwickler im Firmennetz-
werk:
1.
Ziehen Sie den Stecker aus der Netzwerkkarte des PCs.
2.
Formatieren Sie die Festplatte neu und richten Sie Ihren
PC von Hand so ein, wie Sie ihn haben möchten.
3.
Installieren Sie nichts, was im entferntesten für eine au-
tomatische Softwareverteilung missbraucht werden könnte.
4.
Verbinden Sie den PC wieder mit dem Netzwerk.
5.
Stellen Sie eine manuelle Netzwerkverbindung zu Ihrem
Fileserver her, damit wenigstens ein automatisches Backup
Ihrer Dateien stattfindet.
6.
Nehmen Sie abends die lokale Festplatte mit nach Hause.
7.
Schließen Sie das Büro ab und hängen Sie ein Schild an
die Türe: „Zutritt für PC-Supporter und Raumpfleger ver-
boten!“.
Wenn Sie diese Maßnahmen gewissenhaft befolgen, sollten Sie
in einem relativ stabilen Umfeld programmieren können.
4.13.5
Die wunderbare Welt der EDV oder nichts passt zusammen
Es gibt gute Gründe dafür, warum man nicht nur die Entwick-
lungswerkzeuge des Datenbankherstellers verwenden möchte
(noch bessere Gründe gibt es, warum man nur Programme des
Datenbankherstellers verwenden sollte). Beispielsweise könnte
man ja auf die Idee kommen, eine ORACLE-Datenbank zu-
sammen mit einer MS-ACCESS-Benutzeroberfläche zu verwen-
den, weil ohnehin auf allen PCs MS-Office installiert ist. Und
für Auswertungen möchte man gerne CRYSTAL-Reports ver-
wenden, weil dies Firmenstandard ist. Theoretisch sollte dies
auch funktionieren, weil es inzwischen Standardinterfaces wie
ODBC (
O
pen
D
ata
b
ase
C
onnectivity) gibt, die es Programmen
verschiedener Hersteller ermöglichen, mit der Datenbank eines
Fremdherstellers zu kommunizieren. Doch auch hier liegt der
Teufel im Detail und daher möchte ich anhand eines kleinen
Fallbeispieles mögliche Probleme aufzeigen. Es sollen folgende
Komponenten verwendet werden:
