Firebird und MS-SQL-Server auf einem Windows 2008 Server

[MPö]

Derzeit läuft unser Programm auf einem Windows 2003 Server
Es ist geplant einen neuen Server zu installieren, der mit der Server-Betriebssystem Windows 2008 laufen soll.
Bei dieser Gelegenheit wollen wir unsere Datenbank auf Firebird 2.1.? umstellen.
Zusätzlich soll auf dem Server 2 Applikationen mit der Datenbank MS-SQL-Server installiert werden.

Sind bei der Installaion von Firebird 2.1 und MS-SQL auf einem Server Probleme/Einschränkungen bekannt?

[mkinzler]

Grundsätzlich nicht. Habe hier mehrere MSSQL-Instanzen und zusätzlich FireBird ( allerdings Windows Server 2003 x64)

[MPö]

Danke für die schnelle Antwort

Wir haben verschiedene Installationen auf Windows-2003 Server
Bei einer Installation, diese ist ?zufällig? auf einem Server installiert, auf dem auch eine Anwendung (DATEV)
mit einem MS-SQL-Server installiert ist, verhält sich unser Programm ungewöhnlich, das heißt anders als auf
einem Einzelplatz-PC.

Wenn auf diesem Server in einer Transaktion ein DataSet upzudaten ist, das gerade vorher selektiert und bereits
Upgedatet wurde(nur gepostet, ohne Commit), so hängt sich unser Programm ohne Fehlermeldung ohne CPU-Verbrauch
beim ca. 40. Datensatz nach before post und vor after post auf.
Hat das DataSet weniger als 40 Datensätze, so arbeitet das Programm richtig.
Problem bei Befehlsfolge: first; while not eof do begin end;
Lösung: last; first; while not eof do begin end;

Eigentlich eine Delphi-Frage: Wie trägt das last zur Lösung des Problems bei?

Auf einem Einzel-PC tritt das Problem nicht auf.

Ich werde das Verhalten auf einem Windows-2003 Server ohne MS-SQL-Server überprüfen.

[mkinzler]

Bei mir läuft auch Datev.

[hoika]

Hallo,

Erklär das doch mal genauer.
- welche FIBPlus-Version
- welche Komponente wird benutzt

Zitat:

Eigentlich eine Delphi-Frage: Wie trägt das last zur Lösung des Problems bei?

Warum sollte das eine Delphi-Frage sein ?
Last ist in FIBPlus definiert (jaaa, wegen TDataSet, trotzdem ;) )

Wie sieht denn der Code aus ?
Warum durchläufst du das DataSet für das Update ?
Ist der Update-Code so kompliziert, dass er nicht in SQL funktioniert ?

Zeig doch mal ein bisschen Code.


Das Last sorgt hier vielleicht dafür, dass FIBPlus alle Datensätze lokal rüberzieht
und das while not EOF -> Next quasi lokal läuft.

Dann kommt sich das Update und Select nicht in die Query.


Noch eine andere Möglichkeit.
Kann es sein, dass du eine blockierende Transaktion hast ?
Dass also jemand anders auch diesen Datensatz gerade ändern will ?

Fragen über Fragen ...

Am besten erzeuge eine Test-DB + Test-Programm,
was den Fehler eindeutig reproduziert.


Heiko

[Alfredo]

Da ich DATEV-Anwender und auch der bin, der die Updates einspielt,
habe ich schon vor 2 Jahren beschlossen auf einem DATEV-Rechner nichts
mehr anderes zu installieren.

Seit dem ist Ruhe an der Front und der Support bekommt eine Breitseite
von mir, wenn etwas nicht funktioniert. Ganz entscheidend ist, dass bei
einem Bug mein Betrieb nicht mehr funktionsunfähig ist.

Bei den heutigen Hardwarekosten macht es auch absolut keinen Sinn mehr
sich mit Leuten herumzuärgern, die immer noch der Meinung sind, dass sie
auf der untersten Ebene programmieren müssen und der Kunde gefälligst mit
dem zufrieden sein soll was man ihm anbietet.

Der nicht DATEV-Server läuft derzeit unter Fedora 11(Vorsicht! bleeding edge)
mit Samba sehr stabil.

Das einzig teure an der Konstellation ist der KVM-Switch.

Gruß
Alfred

[MPö]

Die FIBPlus-Version 6.4.1
pFibDataSet
Delphi 7

Alles was laufzeitbedingt lokal gemacht werden kann mache ich lokal wegen:
- Datenbankunabhängigkeit
- Debuggmöglichkeit
- Gewohnheit/Routine

Ich habe eine Testinstallation erstellt.
Dadurch ist gewährleistet, dass keine andere Transaktion gleichzeitig ändert.
Außerdem würde das erst beim commit eine Meldung bringen.

Ich vermute auch, dass der last-Befehl die Daten ?nochmals? lokal holt.
aber warum funktioniert es bis ca. 40 Datensätze?

Wie gesagt: Ich teste das ganze auf einem Server ohne DATEV-Installation.

[Alfredo]

Um ganz sicher zu gehen würde ich erst einmal einen
embedded Firebird testen.
Es ist nicht ausgeschlossen, dass der Windows Server falsche Einstellungen hat.
Wireshark solltest Du auch einmal laufen lassen.

Hast Du einen Classic- oder einen Super-Server.

Gruß
Alfred