Programm friert bei Open ein -> Fehler in gds32.dll

[RSE]

Delphi 5

Hallo,

der Fehler tritt unregelmäßig und unabhängig vom ausgeführten SQL an verschiedenen Stellen im Programm auf. Das Bild ist immer das gleiche: Zugriffsverletzung in CharUpperBuffA [2] während Query.Open [1] -> Query wird freigegeben [3] und das Programm hängt bei WaitForMultipleObjects [4].

Delphi-Quellcode:

  Query := TIBOQuery.Create(IB_Connection);
  try
    Query.IB_Connection := IB_Connection;
    Query.KeyLinksAutoDefine := GetEditableSelectResult;
    Query.RequestLive := GetEditableSelectResult;
    Query.SQL.Append(SQL);
    try
      Query.Open; // [1]
    except
      on E:Exception do
      begin
        Log('Fehler beim Öffnen der Query'#13#13 +
          'Fehlermeldung:'#13 + E.Message + #13#13 +
          'Fehlerverursachendes SQL:'#13 + Query.SQL.CommaText);
        raise; // Ausführung der Prozedur trotzdem abbrechen, Query freigeben
      end;
    end;
    try
      // Tue Was
    finally
      Query.Close;
    end;
  finally
    Query.Free; // [3] hier hängt er sich auf - siehe Callstack
  end;

Code:

7c91df48 +00a ntdll.dll                                    NtWaitForMultipleObjects           [4]
7c80958a +000 kernel32.dll                                 WaitForMultipleObjectsEx
7c80a110 +013 kernel32.dll                                 WaitForMultipleObjects
40547176 +003 gds32.dll                                    gds__thread_enter
40543b85 +065 gds32.dll                                    isc_dsql_free_statement
00522e77 +107 CCCClient.exe IB_Components                  TIB_Statement.SysUnprepare
005220b5 +065 CCCClient.exe IB_Components                  TIB_Statement.SysDeallocate
00521484 +030 CCCClient.exe IB_Components                  TIB_Statement.Unprepare
0055144f +01b CCCClient.exe IBDataset                      TIBODataset.Unprepare
005509a4 +014 CCCClient.exe IBDataset                      TIBODataset.Destroy                [3]
00403a5c +008 CCCClient.exe System               3530   +4 TObject.Free
00d55017 +137 CCCClient.exe CZ_Lib                351  +33 ExecuteSQL
0040423a +02a CCCClient.exe System               4715  +15 @HandleFinally
7c93ab7c +103 ntdll.dll                                    RtlUnwind
004041b6 +12e CCCClient.exe System               4654 +141 @HandleOnException
7c91e485 +009 ntdll.dll                                    KiUserExceptionDispatcher
7e36aebf +080 user32.dll                                   CharUpperBuffA                     [2]
40542ddb +16e gds32.dll                                    isc_dsql_execute2_m
40542bda +183 gds32.dll                                    isc_dsql_execute2
40542a4e +01a gds32.dll                                    isc_dsql_execute
00523ff0 +050 CCCClient.exe IB_Components                  TIB_Statement.API_Execute
00529d7d +005 CCCClient.exe IB_Components                  TIB_Dataset.SysExecSelect
00523219 +071 CCCClient.exe IB_Components                  TIB_Statement.SysExecStatement
00522f90 +098 CCCClient.exe IB_Components                  TIB_Statement.SysExecute
00529b98 +060 CCCClient.exe IB_Components                  TIB_Dataset.SysExecute
0052955f +10b CCCClient.exe IB_Components                  TIB_Dataset.SysOpen
0052919c +048 CCCClient.exe IB_Components                  TIB_Dataset.Open
00552798 +13c CCCClient.exe IBDataset                      TIBODataset.InternalOpen
004d1c9e +022 CCCClient.exe Db                   8260   +2 TDataSet.DoInternalOpen
004d1d6e +02e CCCClient.exe Db                   8289   +4 TDataSet.OpenCursor
004d1c09 +05d CCCClient.exe Db                   8242  +12 TDataSet.SetActive
004d1a6a +00e CCCClient.exe Db                   8203   +1 TDataSet.Open                      [1]
00d54f66 +086 CCCClient.exe CZ_Lib                334  +16 ExecuteSQL

Ist euch so etwas schon einmal untergekommen? Was würdet ihr tun, um das zu verhindern? Das Programm wird in einem Callcenter benutzt während wir mit den Anrufern sprechen. Solche Hänger kommen mehrfach täglich vor. Ist natürlich ungünstig, wenn das mitten im Gespräch passiert...

[mkinzler]

Warum Append?
Besser

Delphi-Quellcode:

Query.SQL.Text

direkt setzen.

[RSE]

Korrekt! :roll: Hilft aber leider nicht bei der Problemlösung. :( Ich werde es trotzdem ändern. :wink:

[neo4a]

Weise Deinem Query eine explizite TIB_Transaction zu.

[RSE]

@neo4a:
Kannst du mich zu den Hintergründen deines Lösungsansatzes aufklären?

Soweit ich weiß, startet IBO eine Standardtransaktion, die überall verwendet wird, wo nicht explizit eine andere Transaktion angegeben wird. Aktuell verwenden wir nur diese Standardtransaktion und nutzen das AutoCommit-Feature von TIBODatabase. Die im ersten Post zitierte Prozedur wird immer dann verwendet, wenn ein SQL-Statement (kann auch eine Abfrage sein) nur an einer Stelle benötigt wird und sich somit keine eigene Query etc. im DM lohnt. Momentan bekommen wir damit den Stand der DB von all dem, was mittels Query.Post bestätigt wurde. Dieses Verhalten darf sich nicht ändern. Leider habe ich keine umfassenden Kenntnisse von Datenbanken, um die Auswirkungen einer eigenen Transaktion umfänglich abschätzen zu können. Ich kann mir aber z.B. vorstellen, dass das die Ausführungsgeschwindigkeit (merklich???) und evtl. Sichtbarkeiten von Änderungen beeinflusst. Letzteres darf wie gesagt nicht sein.

[neo4a]

In allen meinen AdHoc-Abfragen habe ich immer dieses Konstrukt verwendet:

Delphi-Quellcode:

  
aQuery := TIB_Query.Create(nil);
try
  with aQuery do 
  begin
    sql.text:=Format(' select acc_profil from t_lms_account where nr=%d for update ',[lms.accountnr]);
    ib_Connection  := dm.IB_TransactionDefault.IB_Connection;
    ib_transaction := dm.IB_TransactionDefault;
    open;
    Edit;
    FieldByName('acc_profil').AsString := aProfile.AsString;
    Post;
  end
finally
  aQuery.free;
end;

und bin damit einer frühen Empfehlung von Jason gefolgt. Im produktiven Einsatz seit 1998 ist bei mir der von Dir geschilderte Fehler nie aufgetreten.

Gleichwohl gibt es beim Einsatz von Firebird (meine Erfahrung bis V. 2.1) einige Fallstricke. Einer der Wesentlichen: Auf Server und Client muss immer die gleiche gds32.dll verwendet werden. Ich habe dazu diese Datei in das Programm-Verzeichnis gelegt, damit sie nicht durch andere Installationen überschrieben wird (da gab's mal z.B. eine populäre Telefon-CD). Damit sind einige "komische" Effekte aus der Anfangszeit verschwunden.

Zur Transaktion: Es gibt keinen Perfortmance-Verlust, da jede SQL-Abfrage ohnehin in einer Transaktion abläuft. Benutzt Du Isolation = tiCommitted, solltest Du auch kein Problem mit der Sichtbarkeit haben. IBO verwendet verschieden Timer, um Deadlocks zu lösen. Ich denke, dass bei Dir dieser Fall auftritt. Man sollte z.B. in jedem Formular, eine eigene Transaktions-Komponente verwenden.

Error-Handling: Habe ich zentral auf IB_Connection.OnError abgearbeitet und nicht pro Query.

[RSE]

@neo4a:
Danke für den ausführlichen Post! Da sind einige Lösungsansätze enthalten, die ich ab Montag mal der Reihe nach abarbeiten werde.

Zur Transaktion: Ich dachte an die Erstellung einer neuen Transaktion auf dem Server. Aber der Zeitbedarf dafür ist sicherlich wenn, dann nur im Hochleistungsbereich interessant.:wink:

Zitat:

Zitat von neo4a

IBO verwendet verschieden Timer, um Deadlocks zu lösen.

Heißt das, wenn ich vor Query.Free lange genug warte, dann löst sich der Deadlock von selbst bzw. tritt nicht auf? Das werde ich mal probieren - besser lange warten als ewig warten. :thumb:

Zitat:

Zitat von neo4a

Man sollte z.B. in jedem Formular, eine eigene Transaktions-Komponente verwenden.

Im Moment haben wir gar keine... Ich weiß aber, dass IBO da im Hintergrund was macht. Werde mich am Montag nochmal genauer damit beschäftigen, wenn ich die Zeit finde.

IB_Connection.OnError werde ich mir dann auch mal zu Gemüte führen.


Jetzt wünsche ich allen erst mal ein schönes Woe, ich melde mich auf alle Fälle nächste Woche wieder, wenn es Neues gibt.

[RSE]

Ich habe die Versionen der gds32.dll überprüft. Hier alle Versionen der beteiligten Komponenten (falls was fehlt bitte nachfragen!):

• Delphi 5
• IBO Version 3.4.Ce (TIBODataBase, TIBOQuery)
• gds32.dll Version 6.0.1.0 (in System32 auf WinXP, keine gds32.dll im Programmverzeichnis)
• InterBase Server 6.1 auf Linux

Ich habe versucht, die tatsächlich zur Laufzeit geladene gds32.dll herauszubekommen und zu prüfen. Das schlägt leider fehl, weil IBO 3.4 noch kein TIB_SessionBase.GDS_Handle hat - das ist im Quelltext auskommentiert - und EnumProcessModules - zum Durchsuchen aller geladener dlls - ist in Delphi 5 offenbar noch nicht bekannt gewesen.
Wir benutzen TIBODataBase.Isolation = tiCommitted und TIBODataBase.AutoCommit = True. Gibt es da irgendwelche bekannten Versionskonflikte?

Bzgl. der Transactions steht in der Hilfe folgendes:

Zitat:

Here are some hints for working with IB Objects transactions:
With IBO three conceptual aspects of transaction need to be considered. They are the physical transaction, the logical transaction and whether the transaction is explicit. Each has its own behavior and in many cases the behaviors overlap. Other factors, such as isolation, also affect the behaviors.

Physical Transactions
· IBO automatically takes care of starting the physical transaction. It is not necessary to start the physical transaction explicitly yourself.
· It is the physical transaction which needs to be kept as short as possible so that the server is not prevented from doing its garbage collection.
· It is where the settings that provide the isolation, lockwait, recversion, and so on, take effect.
· The physical transaction forms the foundation for the logical and explicit transactions.

Long Transactions
A physical transaction of long duration can lead to severe performance degradation and, eventually, a server crash if it is left for more than a day or so in a moderately active database environment. A high-volume database could show signs of degradation within a day.

End of the Physical Transaction
A physical transaction is ended when Commit[Retaining], Rollback[Retaining], Refresh() or Close is called. The same methods also end a logical unit of work and an explicit transaction.

Oldest Active Transaction (OAT) Management
OAT (Oldest Active Transaction) Management is IBO's set of automated features that close the physical transaction for you. Provided you avoid or carefully manage the cases where the OAT management is suspended, you will not have any problems with long physical transactions in your applications.

Here are the cases that prevent IBO from automatically advancing the OAT:
1. You are not using cached updates, AutoCommit is false and you post any change to the database.
This flags the transaction as active (tsActive). The OAT stuff is suspended whilst a transaction's state is tsActive. You must call Commit[Retaining], Rollback[Retaining], LosePoint, SavePoint or Refresh() to resolve the active state of the transaction and allow the OAT stuff to resume.
2. You are using PessimisticLocking and you have a row in dssEdit state.
In order to give duration to the lock, the transaction must be held open. As soon as the row is posted or cancelled, the lock ends, the former rules apply and OAT behavior resumes.
3. You use the tiConcurrency isolation level.
OAT will not advance, because tiConcurrency tells the server that you want a snapshot view of the database. If physical transactions were to able to come and go in order to advance the OAT, the snapshot view would be corrupted. Each time a new transaction is started with tiConcurrency you get a fresh view of the database because other user's committed changes become visible.
4. You have a SELECT statement that will return thousands of rows and you open it but don't fetch all the records.
This forces a cursor to be held open on the server until all the rows have been fetched. Eventually this situation would be overcome by the background fetching that begins taking place in order to free up the cursor. If you set the CommitAction to caInvalidateCursor then it will just get refreshed for you and there won't be a problem.

It is generally inadvisable to leave large datasets open where all records are not fetched in.
Be sure to get familiar with the TimeOutProps settings because it is possible there to ensure that the OAT advancement issues can be dealt with.

Logical Transactions
Consider a logical transaction to be the unit of work that the user is performing. IBO will automatically keep track of your logical transaction for you.
Implicit Logical Transaction
Use the TransactionIsActive property to determine whether you are in an implicit logical transaction.
· If AutoCommit is true, the implicit logical transaction will be limited to the duration of time that any dataset is in an edit state. As soon as it is posted, the transaction is auto-committed and the implicit logical transaction ends.
· If AutoCommit is false then the implicit logical transaction will start from the moment at which a dataset is put into an edit state and will persist after a change is posted. It will not finish until the transaction is ended by explicitly calling one of the methods to end it.
· If a dataset is cancelled and no other changes had been posted then the implicit logical transaction will be ended automatically.

Explicit Transactions
· An explicit transaction is initiated by calling the StartTransaction method. It will persist until one of the methods to end the unit of work is called.
· LosePoint and SavePoint does not end an explicit transaction.
· The InTransaction property is used exclusively to determine whether you are in an explicit transaction. It does not indicate the status of an implicit logical transaction or of the underlying physical transaction.
· AutoCommit=True behavior is suspended during an explicit transaction and all changes posted to the server remain in the transaction, i.e. they are not committed when a dataset's Post method is called.

AutoCommit
· Setting AutoCommit to True allows you to avoid taking explicit control of logical transactions. It will generate an immediate SavePoint when you activate the transaction by posting a change to a dataset, executing a DML statement, etc. Everything becomes committed on the server the moment it is executed. In these conditions, there is no logical transaction to worry about.
· If AutoCommit is false, you need to call LosePoint, SavePoint, CommitRetaining, Commit, RollbackRetaining, Rollback or Refresh() in order to process a unit of work. These methods all end the logical transaction whether it is implicit or explicit.

In der Hilfe zu TIB_Database (Superklasse von TIBODatabase) steht folgendes:

Zitat:

In the case where a statement's or dataset's IB_Connection property is not a TIB_Database class, and its IB_Transaction property is left blank, it will create its own internal transaction. If you made the choice to avoid working with simultaneous transactions, this behavior could give rise to the undesirable effect of having different statements and datasets being kept within different transaction contexts.

Ich würde da jetzt mal reininterpretieren, dass für jede Query bei Bedarf automatisch eine eigene Transaktion angelegt wird (von Edit bis Post). Seht ihr das genauso?

Ich werde folgende Konstruktion ausprobieren, in der Hoffnung, dass der Vorschlag mit den IBO-Timern Erfolg bringt und der Konflikt intern in einem anderen IBO-Thread provoziert wird:

Delphi-Quellcode:

  Query := TIBOQuery.Create(IB_Connection);
  try
    Query.IB_Connection := IB_Connection;
    Query.KeyLinksAutoDefine := GetEditableSelectResult;
    Query.RequestLive := GetEditableSelectResult;
    Query.SQL.Append(SQL);
    try
      Query.Open;
    except
      on E:Exception do
      begin
        Log('Fehler beim Öffnen der Query'#13#13 +
          'Fehlermeldung:'#13 + E.Message + #13#13 +
          'Fehlerverursachendes SQL:'#13 + Query.SQL.CommaText);
        // Hoffen, dass sich das Aufhängen bei der Freigabe mittels WaitForMultipleObjects durch vorheriges Warten erledigt
        for i := 300 downto 0 do // sollte ein paar Sekunden entsprechen
          Sleep(0); // verwirft den Rest der Zeitscheibe
        raise; // Ausführung der Prozedur trotzdem abbrechen, Query freigeben
      end;
    end;
    try
      // Tue Was
    finally
      Query.Close;
    end;
  finally
    Query.Free;
  end;

[neo4a]

Server- und IBO-Version sind sehr alt. Ich kenne nicht Dein Budget, aber zumindest für den Server gibt es mit Firebird eine gute Alternative. Ich habe zu Zeiten von IBO 3.X mit Firebird 1.03 keine Probleme gehabt.

Das "Einfrieren" sieht mir - wie gesagt - ganz nach einem Deathlock aus. Du kannst dieses Verhalten recht leicht nachstellen, indem Du einen Datensatz mit einem SQL-Tool (z.B. IB_SQL) editierst und die Transaktion nicht beendest. Dann gehst Du mit Deiner App (sofern sie in dem Alter noch gehen kann) auf diesen Datensatz und tust, was Du tun willst. Überprüfe, ob da was einfriert.

Kannst Du so das Verhalten Deiner App reproduzieren, dann kann man Lösungen suchen, alles andere ist Mutmaßung und führt eigentlich zu nichts.

[RSE]

Zitat:

Zitat von neo4a (Beitrag 1129647)

Server- und IBO-Version sind sehr alt.

Da stimme ich völlig mit dir überein. Da das Programm aber noch viel schwerfälliger ist, als die DB-Version alt, und die Programmierkapazitäten (genau wie die im DB-Management) äußerst knapp sind, muss ich wohl noch ´ne Weile damit auskommen... :(

Zitat:

Zitat von neo4a (Beitrag 1129647)

Das "Einfrieren" sieht mir - wie gesagt - ganz nach einem Deathlock aus. Du kannst dieses Verhalten recht leicht nachstellen, indem Du einen Datensatz mit einem SQL-Tool (z.B. IB_SQL) editierst und die Transaktion nicht beendest. Dann gehst Du mit Deiner App (sofern sie in dem Alter noch gehen kann) auf diesen Datensatz und tust, was Du tun willst. Überprüfe, ob da was einfriert.

Kannst Du so das Verhalten Deiner App reproduzieren, dann kann man Lösungen suchen, alles andere ist Mutmaßung und führt eigentlich zu nichts.

Das ist eine Idee. Ich bin allerdings sehr skeptisch, ob das glücken wird, weil:

1. Die Abfragen im Programm, die den Fehler verursachen sind simple SELECT-Abfragen, keine Updates etc.
2. Wäre es ein Deadlock auf der DB aufgrund von Zugriffsbeschränkungen durch andere Transaktionen, dann sollte es trotzdem keine Zugriffsverletzung in Modul gds32.dll geben

Ich werde morgen berichten, was dabei herausgekommen ist.

Gehen wir mal davon aus, dass es sich tatsächlich um einen Bug in der DLL handelt. Wir setzen hier IBExpert ein. Dort gibt es eine gds32.dll von 2004 (Version 1.5.2.4731 für Firebird 1.5), die offenbar für die Verbindung zu unserem Interbase 6.1 verwendet wird, wenn ich die IBExpert-DB-Einstellungen richtig lese. Meinst du es ist eine gute Idee diese neuere dll testweise auf den Clients zu verwenden, auf denen unser Programm läuft? IBExpert läuft sehr stabil auf unserem IB 6.1 Server.

[neo4a]

Zitat:

Zitat von RSE (Beitrag 1129661)

die Programmierkapazitäten (genau wie die im DB-Management) äußerst knapp sind, muss ich wohl noch ´ne Weile damit auskommen... :(

Manchmal kostet Arbeit eben auch Geld.

Zitat:

Zitat von RSE (Beitrag 1129661)

Meinst du es ist eine gute Idee diese neuere dll testweise auf den Clients zu verwenden, auf denen unser Programm läuft? IBExpert läuft sehr stabil auf unserem IB 6.1 Server.

Dieses DB-Tool läuft im ständigen Multiuser- Zugriff?! Wie auch immer, ich habe es eigentlich nie gebraucht und kann nicht beurteilen, ob es so als Referenz taugt.

Wie gesagt, kannst Du den/die Fehler nicht nachstellen, sind alle Deine weiteren Versuche wie reines Voodoo: Du kannst nur hoffen, dass es hilft.

[Lemmy]

Hi,

Zitat:

Zitat von RSE (Beitrag 1129661)

die Programmierkapazitäten (genau wie die im DB-Management) äußerst knapp sind, muss ich wohl noch ´ne Weile damit auskommen... :(

Aber jede Menge Zeit so einen Fehler zu suchen ist vorhanden? Keine Angst, das soll jetzt kein Vorwurf sein, ich war selbst oft genug in dem Hamsterrad gefangen. Du musst relativ bald an den Punkt kommen wo Du das ganze stoppst und grundlegende Umbauten vornimmst. Die IB6-Firebird 1.5 Umstellung ist bei mir schon lange her, aber ich war der Meinung dass das noch relativ schmerzfrei geht, d.h. einfach IB deinstallieren FB installieren und gut ist (nicht vergessen die DB per Backup zwischen den Versionen zu verschieben). Wenn Du dann noch einen alternativen Server dafür nimmst, sollte der Zeitaufwand doch sehr überschaubar sein und wenn es nichts bringt kannst Du wieder auf IB6 zurück.

Zitat:

Zitat von neo4a (Beitrag 1129694)

Wie gesagt, kannst Du den/die Fehler nicht nachstellen, sind alle Deine weiteren Versuche wie reines Voodoo: Du kannst nur hoffen, dass es hilft.

[RSE]

Zitat:

Zitat von neo4a (Beitrag 1129694)

Manchmal kostet Arbeit eben auch Geld.

Ich glaube in dem Fall kostet es uns mehr Geld die Arbeit nicht zu investieren, aber bis diese Erkenntnis durchsickert und was bewegt wird, vergeht viel Zeit...

Zitat:

Zitat von neo4a (Beitrag 1129694)

Wie gesagt, kannst Du den/die Fehler nicht nachstellen, sind alle Deine weiteren Versuche wie reines Voodoo: Du kannst nur hoffen, dass es hilft.

Das ist wohl wahr. Aber dass ihr nicht grundsätzlich sagt, dass es nicht gehen kann, motiviert mich dazu, es zu versuchen.8-)

Update
Die Abfrage funktioniert übrigens im Test erwartungsgemäß reibungslos, auch wenn ich mit einem anderen Tool eine offene Transaktion habe.

[neo4a]

Zitat:

Zitat von RSE (Beitrag 1129701)

motiviert mich dazu, es zu versuchen.8-)

Das hast Du falsch völlig verstanden.

Mach doch einmal folgendes:

Setze Dir eine VMWare-Umgebung auf mit mindestens 2 Instanzen.

In einer VM-Instanz installieren Dir Dein Unix mit dem Interbase-Server. Ist auch eine schöne Übung für den Ernst-Not-Fehler-Fall.

In der 2. VM- Instanz laufen so viele Clients wie möglich.

Modifiziere Dein Client- Programm mit einem Timer mit Random-Intervall, der die unterschiedlichen Lookup-Queries permanent feuert. Überprüfe visuell oder programmtechnisch, ob die Clients nun einfrieren.

Wenn das Einfrieren klappt: Gut, dann ist das Problem im Labor reproduzierbar. Wenn nicht, dann lasse Deine VM-Clients in einer Arbeitspause (arbeiten CallCenter auch nachts?) auf den realen Server los. Kommt es dann zum Einfrieren, dann liegts am IB-Server oder der Netzwerkumgebung (Switch, Firewall etc.).

Die Virtualisierung kostet nichts als Arbeit und hilft Dir, Dein Szenario systematisch zu isolieren. Weniger Voodoo, mehr Ergebnisse.

[RSE]

Zitat:

Zitat von neo4a (Beitrag 1129713)

Weniger Voodoo, mehr Ergebnisse.

Und erheblich mehr Aufwand und deshalb nicht vertretbar. Mit verhältnismäßig wenig Aufwand werde ich jetzt die besagte gds32.dll von 2004 testen. Entweder es bringt was oder nicht. Wenn nicht, dann müssen wir damit leben und haben einen Grund mehr, den Umstieg auf Firebird voranzutreiben. :wink: Ich habe schon mehr als einen halben Tag da reingesteckt, mehr als genug Arbeit. Jetzt probier ich also noch etwas Voodoo und dann hat sich die Sache erledigt (entweder zum Guten oder ohne Ergebnis).

Ich werde nächste oder übernächste Woche berichten, was bei dem Voodoo rausgekommen ist.

[RSE]

Es deutet alles darauf hin, dass die gds32.dll von 2004 scheinbar funktioniert, dabei aber die Datenbankdatei zerschießt. Zum Glück habe ich sie nur mit der Testdatenbank benutzt...

[tsteinmaurer]

Zitat:

Entweder es bringt was oder nicht. Wenn nicht, dann müssen wir damit leben und haben einen Grund mehr, den Umstieg auf Firebird voranzutreiben.

D.h. du verwendest noch InterBase 6 OpenSource? Wenn ja, dann würde ich das Weite suchen. :-D Ernsthaft, diese Version ist eine Ansammlung von bekannten Bugs inkl. der Beschädigung der Datenbank. Sollte es sich um eine ernsthafte Anwendung handeln, dann sollte man mit dem Umstieg lieber gestern begonnen haben. Firebird 2.5 ist zwar die aktuellste Version, aber da muss man dann auf die neueste IBO Version gehen, alle SQLs durchtesten etc ... Ev. könnte man auch schrittweise vorgehen und z.B. mal 1.0/1.5 zum Einsatz bringen. Die gibt es nach wie vor als Download. Für Umstiegs-Consulting stehe ich gerne zur Verfügung. :lol:

[RSE]

Kannst du eine Seite nennen, auf der diese Bugs aufgelistet sind? Wär sicher hilfreich die mal gelesen zu haben, wenn man damit arbeitet. :wink:

Wenn wir umsteigen, wollen wir auch von IBO weg. Delphi XE hat da wohl brauchbare Komponenten inzwischen. Das hat allerdings mein Kollege ausgekundschaftet, ich kann da noch nicht viel dazu sagen. Aber wenn, dann steigen wir gleich auf eine aktuelle Firebird um. Wenn dabei Probleme auftreten, dann poste ich hier wieder. :wink:

[neo4a]

Zitat:

Zitat von tsteinmaurer (Beitrag 1131197)

Sollte es sich um eine ernsthafte Anwendung handeln,

Das kann ich mir eigentlich nicht mehr vorstellen, sonst hätte er die wirklich ernsthaften Hilfs-Ansätze nicht so abgebügelt mit der Plattitüde aller Unterforderten ("keine Zeit"). ;)

[tsteinmaurer]

Zitat:

Zitat von RSE (Beitrag 1131577)

Kannst du eine Seite nennen, auf der diese Bugs aufgelistet sind? Wär sicher hilfreich die mal gelesen zu haben, wenn man damit arbeitet. :wink:

Bugs fixed Section der Firebird 1.0 Release Notes:
http://www.firebirdsql.org/file/docu...leaseNotes.pdf

und in weiterer Folge auch von 1.5:
http://www.firebirdsql.org/file/docu...leaseNotes.pdf

:thumb:

[RSE]

Zitat:

Zitat von neo4a (Beitrag 1131588)

Zitat:

Zitat von tsteinmaurer (Beitrag 1131197)

Sollte es sich um eine ernsthafte Anwendung handeln,

Das kann ich mir eigentlich nicht mehr vorstellen, sonst hätte er die wirklich ernsthaften Hilfs-Ansätze nicht so abgebügelt mit der Plattitüde aller Unterforderten ("keine Zeit"). ;)

Wie schon im ersten Beitrag geschrieben handelt es sich um die Software in einem Callcenter. Sie wird im Haus entwickelt und ausschließlich im Haus verwendet. Es gibt ausführende Programmierer und Kaufleute, die sagen was in welcher Zeit gemacht werden muss. Das beschränkt sich im Allgemeinen darauf, das jeweils anstehende Projekt zum Laufen zu bringen. So ein Projekt hat allerdings einen Starttermin, der drückt, so dass für die Umsetzung von Neuerungen immer nur sehr wenig Zeit ist. Wir haben niemanden in der Firma, der ein Konzept gegen den Verfall entwickeln und den Zeitaufwand für dessen Umsetzung gegenüber den Kaufleuten rechtfertigen kann. Ich habe mir das Programmieren parallel zum Abi größtenteils selbst beigebracht, dann Informatik studiert - leider nicht auf Softwaretechnik spezialisiert. Mit etwa 8 Jahren Hobbyprogrammiererfahrung bin ich nun derjenige gewesen, der erstmals Programmteile, die in allen Projekten gleich waren (Auswahldialoge bekannter Personen etc.) projektübergreifend nutzbar machte. Bis dahin wurde selbst so etwas von Projekt zu Projekt kopiert. Richtig gelesen, kopiert! Es gibt nicht mal ein Projekt, von dem immer kopiert wird, sondern da wird ein passendes gesucht und alle Neuerungen aus anderen Projekten auch dort eingebaut. Grausig, aber wahr. Solch ein Standardprojekt war mal anvisiert, bei deren Umsetzung sollte dann aber gleich einiges geändert werden. Bei jeder Besprechung wurden die Änderungswünsche mehr, bis es aus Zeitmangel gestorben ist - die laufenden Projekte gehen schließlich vor. Die vielen Bugfixes, die ich bis dahin eingearbeitet hatte sind quasi mit gestorben. Es ist allen im Haus bekannt, dass sich etwas ändern muss, aber es gibt einfach nicht genügend freie Programmierkapazitäten, um wirklich etwas zu reißen.

Die Release Notes werde ich mir am Montag auf Arbeit mal zu Gemüte führen. Wenn sie nicht wieder mal noch schnell eine Bestellmaske brauchen, weil jemand gemerkt hat, dass man ohne Maske keine Bestellungen bearbeiten kann. Aber das war ja heute erst der Fall...

[neo4a]

Zitat:

Zitat von RSE (Beitrag 1131821)

Sie wird im Haus entwickelt und ...

Ich kenne eine solche Ausgangslage und Du bist sehr ausführlich auf den Punkt Deiner Problemkette eingegangen, den ich am wenigsten einschätzen kann und den ich auch gar nicht so sehr meine: das Programm selbst. Das Programm kommuniziert über eine Dll mit dem Server - Punkt 2 und 3 Deiner "Problemkette". Es ist simpel und bei weitem nicht so aufwändig, mittels Virtualisierung Laborbedingungen zu schaffen, die es Dir ermöglichen, Dein Problem nachzustellen, ohne auch nur eine Zeile Code zu verändern.

Also fange endlich einmal an, Dir ein transportables Backup Deiner DB anzulegen, dass Du in eine Firebird-Versionen ab 1.0.3 importieren kannst (Tipp: backup/restore als Batch, FB-Server unter virtualisiertem Windows-OS ab WinXP). Gegen diese Firebird-DB solltest Du Dein Programm ohne Probleme fahren können, indem Du die gds32.dll der Server-Version auch am Client benutzt. Du musst dazu kein Client-Setup machen; es reicht die gds32.dll im Programmverzeichnis.

Dieser Aufbau ist Dir ja nicht nur bei Deinem aktuellem Problem nützlich, sondern auch bei Deiner laufenden Entwicklung, denn Du programmierst doch nicht wirklich gegen die Produktions-DB, oder?!

[RSE]

Da wir für das Programm auch Eingangsdaten aus der DB lesen, haben wir eine Test-DB im Netz, mit der alle 3 Programmierer arbeiten und die vom Datenmanagement mit Testdaten gefüllt wird.

Was ich vielmehr mit meinem letzten Post erklären wollte, ist die Ursache des Zeitmangels, der mich dazu gebracht hat, das ursprüngliche Problem dieses Threads zu ignorieren, weil es wesentlich wichtigere Probleme bei uns gibt.