Frage zu Stored Procedures des Interbase 6.0

[Jan Steinhardt]

Hallo,
ich habe eine Frage zu den Stored Procedures des Interbase 6.0:

Ich möchte eine Delphi-Anwendung, die mit ADO auf eine Access-Datenbank zugreift gerne auf eine Interbase-Datenbank umstellen. Dies soll möglichst ohne große Änderungen an der Benutzeroberfläche geschehen.

Ich habe 2 Tabellen, in denen Termine für Fahrzeugvermietungen stehen. Die Beziehungen könnt Ihr unter http://www.jsse.de/files/beziehungen.gif genauer sehen. Die Daten aus diesen 2 Tabellen werden momentan innerhalb der Anwendung eine Speichertabelle geschrieben. Das Endergebnis könnt Ihr hier sehen: http://www.jsse.de/files/grid.gif In den einzelnen Feldern der Speichertabelle stehen Zahlenwerte (1=Nur vormittags, 2=Nachmittags, 3=Ganzer Tag), die dann entsprechend gezeichnet werden.

Nun das genaue Problem: Die anwendung soll möglichst wenig Netzwerklast produzieren, da sie teilweise über 64 kBit-Leitungen kommunizieren soll. Die bisherige Arbeitsweise (alles auf dem Client) kommt also nicht in Frage. Kann ich diese Umwandlungsroutine nicht irgendwie in eine Stored Procedure packen und dem Interbase-Server die Drecksarbeit überlassen?

Danke im voraus!

MfG Jan

[Andreas Kosch]

Hallo,

in diesem Fall würde ich die Anwendung als Three-tier-Anwendung konzipieren, bei der das eigentliche Programm auf einem Application Server läuft (der direkt über eine LAN-Verbindung auf den Datenbank-Server zugreift, wenn separate Server notwendig werden). Der Client ruft dann nur den Application Server auf, ohne eine direkte Datenbankverbindung zu benötigen. Somit müssen über die ISDN-Leitung nur die in der Benutzeroberfläche anzuzeigenden Daten übertragen werden.

P.S: Der InterBase ist für lästige, nicht reproduzierbare Probleme beim Zugriff des Clients über eine Wählverbindung bekannt. Mit einer Three-tier-Architektur umgeht man auch dieses Problem

[Jan Steinhardt]

Hallo,
das Problem ist: Viele der Anwender haben kein NT/2000/XP, sondern teilweise nur Windows 95 im Haus, das kostengünstige DCOM ist also nur eingeschränkt nutzbar:-(

Welche Lösung sollte ich da nehmen? Manuell per TCP/IP Socket, irgendeine Freeware-Middleware ala MidWare von Francois Piette?

MfG Ja

[Andreas Kosch]

Hallo,

Windows 95 ist kein Problem, solange man das frei verteilbare Setup von <i>DCOM 1.3 for Windows 95</i> auf diesen Rechnern installieren kann.

Ansonsten würde alternativ zu TWebConnection bzw. TSocketConnection auch RDS (Remote Data Service) zur Verfügung stehen, wenn ADO (MDAC) auf diesen Rechnern verfügbar ist. RDS entspricht einem clientseitigen ADO-Recordset, nur mit dem Unterschied, dass die Datenmenge über HTTP (Port 80) vom Server zum Client transportiert wird. Das sekundäre Ziel von RDS besteht darin, dem Client die Möglichkeit einzuräumen, beliebige COM-Objekte über HTTP aufzurufen. Aus diesem Blickwinkel betrachtet ist RDS ein allgemeiner COM-Marshaler, der in der Lage ist, DCOM-Aufrufe als Request und Response-Aufrufe über HTTP zu transportieren. Hier sind alle die Datentypen erlaubt, die auch vom Standard-Marshaler für Automation-Aufrufe unterstützt werden

[Jan Steinhardt]

Hallo,
Windows 95 ist schon ein Problem, wenn der DCOM-Server darauf laufen soll... Ich habe das Buch "COM/DCOM/COM+ mit Delphi" schon fast durch:-)

TWebConnection und TSocketConnection? Nicht jeder hat eine Enterprise-Edition:-(

RDS? Den IIS kann ich nicht voraussetzen:-(

Gibts noch irgendwelche anderen Möglichkeiten, die sich ohne viel Aufwand auch mit D6 Pro realisieren lassen?

MfG Ja

[Gesine Kuhlmann]

Hi,

Wie wär's denn mit MySQL als Backend ??

Gruß
Gesin

[Andreas Kosch]

Hallo,

als <B>Server</b>-Betriebssystem Windows 9x einzusetzen, würde ich mir nochmals gründlich überlegen. Wenn es denn überhaupt nicht anders geht, kann man unter Windows 9x das <i>Option Pack für Windows NT 4</i> (kein Schreibfehler) installieren, um <br>
a) den MTS (Microsoft Transaction Server), und <br>
b) den IIS 4 (Internet Information Server) <br>
nachzurüsten. Das Option Pack für Windows NT 4 ist (war?) bei MS frei erhältlich.

Bevor ich so etwas beginnen würde, sollte ein Praxistest Klarheit schaffen, ob Windows 9x überhaupt die benötigte Anzahl <b>gleichzeitiger</b> Netzwerkzugriffe unterstützt. Erst die Server-Version von Windows unterliegen nicht der üblichen Beschränkung auf 10 Verbindungen.

Oder arbeitet die Anwendung nach dem Peer-to-Peer-Prinzip, wo die Datenbanken auf jedem Rechner läuft und somit jeder Client gleichzeitig "Server" sein muss?
&#10

[Gesine Kuhlmann]

Hi,

W9x als Serverbetriebssystem würde ich auch keinesfalls einsetzen. Auch eine Multi-Tier-Lösung ist in diesem Zusammenhang ein Garant für Probleme. Ich kenne keine andere Anwendungsumgebung, die mehr auf eine <b>echte</b> Onlineverbindung angewiesen ist, als ein Buchungssystem. Eine Multi-Tier Lösung, deren primärer Zweck das Caching von Daten ist, kann die Anforderungen prinzipiell nicht erfüllen.

Gruß
Gesin

[Andreas Kosch]

Hallo Gesine,

<b>alle</b> Buchungssysteme über das Internet arbeiten nach dem Three-tier-Prinzip - oder erhält etwa ein Kunde für das Online-Banking eine CDROM mit dem Treiber für die Datenbank und einen echten Benutzername/Passwort-Zugang direkt auf die Datenbank?

Das Grundprinzip von Three-tier besteht darin, zwischen Client und Application Server wieder das uralte <i>Terminal-Host-Prinzip</i> einzusetzen (so wie das ganz am Anfang der Computerei war). Der Client muss nur die Aufgabe der Darstellung der Benutzeroberfläche verwenden, das Programm läuft auf dem Application Server, der lokal im LAN (100 MB-Verbindung) auf den Datenbank-Server zugreift. Wenn man nun zusammenrechnet, wieviel Bytes für die Darstellung der reinen Daten in der Benutzeroberfläche zusammenkommen, macht das bei einer ISDN-Verbindung schon einen Unterschied.

Angenommen, es müssen 100 Datensätze beim Client in einem TDBGrid angezeigt werden: <br>
a) Client/Server: Client holt sich mit 100 Fetch-Aufrufen jeden einzelnen Datensatz vom SQL-Server ab (Ping-Pong-Spiel über das ISDN-WAN), oder <br>
b) Three-tier: Client holt sich mit <b>einem</b> Aufruf einen Datenblock (zum Beispiel <i>RecordSet</i>) bestehend aus 100 Datensätzen ab.

P.S: Der "Weltrecord" für die Transaktionsleistung (Buchungen auf einem Bankkonto) wird auf den ersten 3 Plätzen nur von Systemen gehalten, die als Three-tier-Anwendung (COM+) unter Windows 2000 Server mit dem Microsoft SQL Server 2000 arbeiten (Bsp: 24 zusammengeschaltete Application Server mit 192 CPUs und einem Array aus 2496 Festplatten). Die Details können unter http://www.tpc.org/tpcc/results/tpcc_perf_results.asp nachgelesen werden

[Gesine Kuhlmann]

Hi Andreas,

uups, genaues Lesen aller Beiträge hilft schon weiter... Irgendwie war ich der irrigen Meinung, Du hättest empfohlen auch clientseitig einen Middle-Tier zu installieren.

Gruß
Gesin

[Jan Steinhardt]

Hallo,
es geht um ca. 15 Clients, die selten gleichzeitig auf die DB zugreifen. Den Interbase-Server könnte ich auch auf einer (vorhandenen) Unix-Maschine (leider kein Linux) installieren, mit einem Application-Server hätte ich hingegen einige Probleme. Die Anwendung arbeitet nicht nach dem Peer-to-Peer Prinzip, es soll nur 1 Server/1 Datenbank geben. An das Option Pack kann ich bestimmt noch rankommen, aber ich kann meinem Kunden bestimmt nicht klarmachen, warum er für diese "Mini-Anwendung" einen Webserver braucht, zumal sie sowieso nur in den einzelnen Fillialen genutzt werden soll und nicht von Aussendienst-Mitarbeitern.

Ist das Option Pack eigentlich redistributable?

MfG Ja

[Andreas Kosch]

Hallo,

die Clients benötigen nichts davon (weder MTS noch IIS), wenn die Datenbank zentral auf einem Server liegt. Angenommen, es kann eine echte Three-Tier-Anwendung aufgebaut werden, dann sieht die Situation wie folgt aus: <br>
a) Datenbank-Server (UNIX, Linux, Windows NT oder 2000) <br>
b) Application-Server (Windows 2000 Server), der im gleichen LAN wie der Datenbank-Server hängt <br>
c) Clients, die ab Windows 95 auf den Application Server zugreifen können. <br>
Somit müssen die Clients außer DCOM for Windows 95 nichts installieren (ab Windows 98 ist bereits alles an Bord). Wenn DCOM nicht in Frage kommt, können die Clients auf RDS ausweichen, dann läuft die Kommunikation über Port 80 als HTTP-Datenpakete, wobei dann allerdings auf dem Application Server der IIS 5 (gehört fest zu Windows 2000) aktiviert werden muss

Hallo Jan,

bei dem Mini-Projekt reicht es vielleicht wirklich, das ganze über eine Stored Procedure zu verwirklichen. Falls Du Dich mit dem Aufbau einer solchen Prozedur nicht so auskennst, sieh Dir die Beispiel-DB "employee.gdb" genauer an. (Z.B. die Prozedur "Org_Chart", in der Daten aufbereitet zurückgegeben werden)

Gruß, Heik