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 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 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 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

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