Firebird und IBObjects

[hanspeter]

Hallo,
ich hatte schon mal geschrieben, dass ich inzwischen mit FB2.0 und IBObjects massive Probleme habe.
Offensichtlich funktioniert der SQL Parser nicht mehr richtig.

Ein Feldname "TEILERGEXEC" wird z.B. nicht aufgelöst und führt zu dem Fehler "Fieldname not found".
In Scripten sind zwingend Leerzeichen an syntaktisch unnötigen Stellen erforderlich.
Einige SQL Anweisungen funktionieren nur, wenn zwischen Schlüsselwort und öffnender Klammer ein Leerzeichen steht u.s.w.
Ich stehe jetzt vor dem Problem, entweder auf FB1.5 und eine funktionierende IBObjects Version zurück zu gehen oder
IBObjects in die Wüste zu schicken und auf ein funktionierendes System zu wechseln.
Dazu habe ich mir UIB bereits einmal angesehen. Mich schreckt aber der geringe Trafik auf der Webseite und der 6 Monate alte RC1 etwas ab.
Was habt ihr mit UIB für Erfahrungen?
Oder gibt es einen anderen Vorschlag für ein funktionierendes System?

Gruß Peter

[Hansa]

Zitat:

Zitat von hanspeter

Oder gibt es einen anderen Vorschlag für ein funktionierendes System?

FIBplus = 250 EUR und Ruhe ist.

[mikhal]

Oder IBDAC von CoreLab. Zwischen 100 USD (ohne Sourcen) und 250 USD (mit Sourcen) plus MwSt.

Grüße
Mikhal

[Lemmy]

Hi,

UIB funktionieren, ich habe diese gerade in einem kommerziellen System eingebaut, allerdings ist da die DB-Funktionalität eher gering (ist ein Berechnungsprogramm).

Die RC1 funktioniert mit der FB2.0 Final ohne Probleme. Was mich stört, ist der umständlich Wechsel der FB-Version (man muss jedesmal die Komponenten neu kompilieren). Die Anbindung an datensensitive Komponenten funktioniert mit dem AlexDataSet (habe ich aber noch nie getestet).

Wie Du bei IBObjects siehst, schützt noch nicht einmal ein kommerzieller Anbieter davor, dass Du eines Tages die Kompoenten wieder wechseln musst.

Grüße
Lemmy

[hanspeter]

Erst mal vielen Dank für die Tips.
Für UIB hatte ich mich interessiert, da ich die Nutzung von IBObjects auf den reinen Datenbankzugriff reduziert habe.
Also Starttransaction -> Daten in speicher lesen -> Commit

Daten bearbeiten .

StartTransaction Daten rückschreiben -> Commit.

Zu FIBUS und 250€...

Für IBObjects habe ich einmal viel Geld bezahlt.
Fast 2 Jahre Updateabstand. 5 bis 6 Monate zur Fehlerbeseitigung.
Was mich bedenklich stimmt ist der Umstand, das auch bei anderen kommerziellen Komponentenherstellern, Delphi offensichtlich
immer mehr auf das Abstellgleis gerät. Neuentwicklungen und extensive Weiterentwicklung scheint nur noch unter Net zu erfolgen.


Gruß Peter

[dataspider]

Hallo Peter,

ich habe ein Altprojekt auch jetzt umgestellt und finde keine Fehler.
Einige Anpassungen musste ich vornehmen, auch auf der Datenbank.

So funktionierten z.B. solche Selects nicht mehr:

SQL-Code:

  select a.name1, b.bezeichnung from adresse a
         left join beispiel b on beispiel.id = a.beispiel_id

Dein Beispiel mit dem Feldnamen läuft bei mir auch sauber, sowohl mit IB_Query als auch mit IBOQuery.
Wenn du noch konkrete Fehler hast, würde ich das versuchen, nachzuvollziehen.

Ich muss allerdings sagen, dass für mich eine Umstellung von IBO auf UIB oder ZEOS, ja nicht einmal auf FibPlus etc. in Frage käme.

Ich würde eher Jason noch mal auf den Nerv gehen.
Wenn ich es nachvollziehen kann, kann ich mich ja auch noch über den Fehler beschweren.
Jason reagiert nicht auf jede Frage, aber Fehler hat er bis jetzt immer beseitigt.

Cu, Frank

[hanspeter]

Zitat:

Zitat von dataspider

So funktionierten z.B. solche Selects nicht mehr:

SQL-Code:

  select a.name1, b.bezeichnung from adresse a
         left join beispiel b on beispiel.id = a.beispiel_id

Cu, Frank

Die funktionieren wenn die Bedingung in einer Klammer und zwischen on und Klammer zwingend ein
Leerzeichen ist.

In Scripten muss z.B. nach Declare Variable ein ; und Leerzeichen stehen.

Also Declare a smallint;Declare b smallint; funktioniert nicht.

Declare a smallint; Declare b smallint; funktioniert.
(Leerzeichen nach ;)

Der obige Konstrukt wird von IBExperts erzeugt, wenn der Quelltext einer SP ausgegeben wird.

Die Anweisung Set Term .. in Scripten erzeugt einen Syntaxfehler.

Bei FB2.0 ist eine Umstellung der Datenbank insofern notwendig, da alle NEW Variablen readonly sind.

Ein SP der von einem Trigger After gesteuert wird, funktioniert nicht mehr.

Beispiel: Eintragen eines neuen Preises, danach alle offenen Bestellungen anpassen, geht nicht mehr vom Trigger
aus.


Gruß Peter

[mkinzler]

Zitat:

Bei FB2.0 ist eine Umstellung der Datenbank insofern notwendig, da alle NEW Variablen readonly sind.

Ist aber sclecht und m.E. nicht sinnvoll, da so der Sinn vieler Trigger (nämlich die Korrektur falscher Werte) verhindert wird. Muß mal meine DBs darauf Testen.

[TBx]

Hallo!

Zitat:

Zitat von hanspeter

Bei FB2.0 ist eine Umstellung der Datenbank insofern notwendig, da alle NEW Variablen readonly sind.

Dies ist in den After-Triggern der Fall. In den Before-Triggern sind die NEW-Variablen selbstverständlich nicht readonly.
Die Änderung der NEW-Variablen in den AFTER-Triggern in Konstanten wurde durchgeführt, da es keinen Sinn macht, einen Datensatz zu ändern, wenn dessen Bearbeitung bereits abgeschlossen ist.
BeforeIndert/Edit werden vor dem Post ausgeführt, AfterInsert/Edit dannach.
Will man unbedingt nach dem Posten noch eine Änderung haben, dann muss man eben eine Update-Anweisung in den Trigger schreiben.

SQL-Code:

select a.name1, b.bezeichnung from adresse a 
         left join beispiel b on beispiel.id = a.beispiel_id

Dies mag der FB2.0 generell nicht. Es wird erwartet, dass in einer Anweisung entweder immer mit alias oderf immer mit Full-Qualifier gearbeitet wird.
Hier hilft einem FB2.0 eigentlich nur, besser lesbaren Code zu erzeugen :wink:

Gruß

Thomas

[dataspider]

Hallo Peter,

Zitat:

In Scripten muss z.B. nach Declare Variable ein ; und Leerzeichen stehen.

Also Declare a smallint;Declare b smallint; funktioniert nicht.

Declare a smallint; Declare b smallint; funktioniert.
(Leerzeichen nach

Der obige Konstrukt wird von IBExperts erzeugt, wenn der Quelltext einer SP ausgegeben wird.

Bei mir erzeugt IBExpert für jedes Declare eine eigene Zeile...

Zitat:

Bei FB2.0 ist eine Umstellung der Datenbank insofern notwendig, da alle NEW Variablen readonly sind.

Ein SP der von einem Trigger After gesteuert wird, funktioniert nicht mehr.

Beispiel: Eintragen eines neuen Preises, danach alle offenen Bestellungen anpassen, geht nicht mehr vom Trigger aus.

In After - Triggern war New IMHO auch bei FB 1.5 ReadOnly. In Before - Triggern kann ich auf New schreibend zugreifen.

Zitat:

Die Anweisung Set Term .. in Scripten erzeugt einen Syntaxfehler.

SET TERM ^ ;
funktioniert bei mir...

Bist du sicher, dass du auch die richtige Client - Dll zur FB - Version einsetzt und du die letzte Version installiert hat?

Cu, Frank

[Hansa]

Zitat:

Zitat von hanspeter

Zu FIBUS und 250€...

Für IBObjects habe ich einmal viel Geld bezahlt.
Fast 2 Jahre Updateabstand. 5 bis 6 Monate zur Fehlerbeseitigung.
Was mich bedenklich stimmt ist der Umstand, das auch bei anderen kommerziellen Komponentenherstellern, Delphi offensichtlich
immer mehr auf das Abstellgleis gerät. Neuentwicklungen und extensive Weiterentwicklung scheint nur noch unter Net zu erfolgen.

Sind 250 EUR ein unüberwindliches Hindernis, dann erst gar nicht weiterlesen. Bzw. die fast unbeschränkte FIBplus-Trial verwenden. Ansonsten : FIBPlus hat kurze Update-Zyklen. Eigentlich ziemlich parallel zu Delphi und IB/FB. Sie bringen diese Updates auch nicht nur raus, dammit es keine Compilerfehler gibt, sondern wegen neuer Funktionen. Mein Paradebeispiel sind immer die SavePoints ab FB 1.5. Eine Delphi Funktion SetSavepoint (s : string); oder GotoSavePoint (s : string); sucht man sonstwo vergebens. Die UIB sind mir zu neu. Wer weiß, was aus denen mal wird. Sie kommen übrigens genauso wie FIBPlus ursprünglich von irgendeiner FreeIB library von ??? Sind halt ein paar Jährchen später an als Devrace. IBObjects sind wie Zeos schon sehr früh ausgeschieden. Zumindest in Punkto Zeos stellt sich das mittlerweile eindeutig als großer Vorteil heraus. :zwinker:

[hanspeter]

Zitat:

Zitat von Hansa

Sind 250 EUR ein unüberwindliches Hindernis, dann erst gar nicht weiterlesen.

Nein das Geld nicht, aber der Arbeitsaufwand.
Eigentlich möchte ich ja mit dem Projekt von Delphi weg.
Zu Chrome oder C#, da bin ich noch am Überlegen. Deshalb will ich in Delphi auch nicht mehr groß
investieren.


Gruß Peter

[Lemmy]

Zitat:

Zitat von hanspeter

Eigentlich möchte ich ja mit dem Projekt von Delphi weg.
Zu Chrome oder C#, da bin ich noch am Überlegen. Deshalb will ich in Delphi auch nicht mehr groß
investieren.

Dann am besten dabei bleiben und die Fehler mit Workarounds ausschalten. Die Zeit dann in den Test von C# und Chrome stecken...

Grüße
Lemmy

[Hansa]

Zitat:

Zitat von hanspeter

Zitat:

Zitat von Hansa

Sind 250 EUR ein unüberwindliches Hindernis, dann erst gar nicht weiterlesen.

Nein das Geld nicht, aber der Arbeitsaufwand.
Eigentlich möchte ich ja mit dem Projekt von Delphi weg.
Zu Chrome oder C#, da bin ich noch am Überlegen.

Der Arbeitsaufwand eine Komponente zu ersetzen steht IMHO in keinem Verhältnis zum Austauschen der Programmiersprache. 8) Wahrscheinlich gehts wohl nur um 100 Zeilen-Programm mit einem Dataset, oder ? Mann, mann. :wall:

[hanspeter]

Zitat:

Zitat von Hansa

Der Arbeitsaufwand eine Komponente zu ersetzen steht IMHO in keinem Verhältnis zum Austauschen der Programmiersprache. 8) Wahrscheinlich gehts wohl nur um 100 Zeilen-Programm mit einem Dataset, oder ? Mann, mann. :wall:

Sorry war zu zeitig weg. Taste hat geprellt Antwort im Folgebeitrag.

[hanspeter]

[quote="hanspeter"]

Zitat:

Zitat von Hansa

Der Arbeitsaufwand eine Komponente zu ersetzen steht IMHO in keinem Verhältnis zum Austauschen der Programmiersprache. 8) Wahrscheinlich gehts wohl nur um 100 Zeilen-Programm mit einem Dataset, oder ? Mann, mann. :wall:

Naja hast ja wie immer Recht.

Ich hatte das in diesem Zusammenhang schon mal geschrieben. Das Programm ist ein klein wenig größer. So etwa 1,2 Mio Quellzeilen.
Die Lebenserwartung > 10 Jahre, deshalb auch die Überlegung von Delphi wegzugehen.
Ich will vorerst mit Hydra von Remobjects weiterarbeiten und alle neuen Module und die auszutauschenden in C# schreiben.

Gruß Peter

[dataspider]

Hi Peter,

in der aktuellen Version (Beta 13) ist ein Bug gefixt:

...
I fixed a parsing bug that caused the SET TERM in scripts to fail.
...

Cu, Frank

[hanspeter]

Zitat:

Zitat von dataspider

Hi Peter,

in der aktuellen Version (Beta 13) ist ein Bug gefixt:

Cu, Frank

Danke habe ich von Jason bereis als email erhalten.

Gruß Peter