Firebird 3 - Feld andere Domain zuweisen

[dataspider]

Ich konnte bisher immer einem Feld eine andere Domain zuweisen.
IBExpert hat daraus immer so was:

Code:

update RDB$RELATION_FIELDS set
RDB$FIELD_SOURCE = 'D_NUMMER'
where (RDB$FIELD_NAME = 'TEST') and
(RDB$RELATION_NAME = 'SYS$LOG')

Bei Firebird 3 kommt folgender Fehler:

Unsuccessful execution caused by a system error that precludes successful execution of subsequent statements.
UPDATE operation is not allowed for system table RDB$RELATION_FIELDS.

Kann ich das jetzt nicht mehr oder gibt es jetzt in der DDL eine Erweiterung?

Danke, Frank

[tsteinmaurer]

Direkte Systemtabellenmanipulation ist in Firebird 3 nicht mehr erlaubt/möglich.

[Lemmy]

Zitat:

Zitat von dataspider (Beitrag 1298522)

Bei Firebird 3 kommt folgender Fehler:

Unsuccessful execution caused by a system error that precludes successful execution of subsequent statements.
UPDATE operation is not allowed for system table RDB$RELATION_FIELDS.

ENDLICH!!! ist die fehleranfällige Möglichkeit vom System unterbunden!

Warum machst Du es nicht so wie es schon immer per SQL richtig ging?

[SQL]
ALTER TABLE test ALTER COLUMN test TYPE DOM_VARCHAR_250
[/SQL]

Leider hat IBExpert viel zu spät darauf reagiert und diese Updatebefehle direkt auf die Systemtabellen ausgebaut. In aktuellen Versionen ist mir davon keiner mehr über den Weg gelaufen

[dataspider]

Vielen Dank!

Zitat:

Zitat von Lemmy (Beitrag 1298530)

Warum machst Du es nicht so wie es schon immer per SQL richtig ging?

:oops: Hab es nicht hinbekommen...

Zitat:

Zitat von Lemmy (Beitrag 1298530)

Leider hat IBExpert viel zu spät darauf reagiert und diese Updatebefehle direkt auf die Systemtabellen ausgebaut. In aktuellen Versionen ist mir davon keiner mehr über den Weg gelaufen

Bei mir (Version 2.15.3.27.1) will er noch die Systemtabellen benutzen. Dann werde ich mal alle Optionen durchgehen, ob ich das in IBExpert beeinflussen kann.
Momentan bin ich noch nicht fündig geworden.

Frank

[mkinzler]

http://ibexpert.net/ibe/index.php?n=...rences#FB3Beta

[dataspider]

Zitat:

Zitat von mkinzler (Beitrag 1298534)

http://ibexpert.net/ibe/index.php?n=...rences#FB3Beta

Dort kann die Antwort leider nicht finden...


Frank

[mkinzler]

Aber den Status der FB3 Unterstützung von IBExpert

[Lemmy]

Zitat:

Zitat von dataspider (Beitrag 1298533)

Zitat:

Zitat von Lemmy (Beitrag 1298530)

Leider hat IBExpert viel zu spät darauf reagiert und diese Updatebefehle direkt auf die Systemtabellen ausgebaut. In aktuellen Versionen ist mir davon keiner mehr über den Weg gelaufen

Bei mir (Version 2.15.3.27.1) will er noch die Systemtabellen benutzen. Dann werde ich mal alle Optionen durchgehen, ob ich das in IBExpert beeinflussen kann.
Momentan bin ich noch nicht fündig geworden.

seit mind. einem Jahr ist die Versionierung auf yyyy.mm umgestellt, d.h. du hast ne ältere Version. Würde ich aber allein deswegen nicht ersetzen (insbesondere wegen der geänderten Nutzungsbedingungen)

[hstreicher]

2015.3.27 ist die aktuellste Version von Ibexpert
ich tippe auf eine Tippfehler 2.15 statt 2015

[dataspider]

Zitat:

Zitat von hstreicher (Beitrag 1298546)

2015.3.27 ist die aktuellste Version von Ibexpert
ich tippe auf eine Tippfehler 2.15 statt 2015

Sorry,
Version 2015.3.27.1 ist korrekt (letzte Woche erst erneuert)...

Frank

[EDIT]
Ich habe das jetzt als Fehlerbeschreibung an IBExpert gesendet.
[/EDIT]

[Perlsau]

Zitat:

Zitat von dataspider (Beitrag 1298522)

Bei Firebird 3 kommt folgender Fehler:

Die aktuelle Firebird 3.0 Beta 1 ist als unstable gekennzeichnet, also instabil und noch nicht für den ernsthaften Einsatz bereit.

[tsteinmaurer]

Zitat:

Die aktuelle Firebird 3.0 Beta 1 ist als unstable gekennzeichnet, also instabil und noch nicht für den ernsthaften Einsatz bereit.

Ändert nichts an der Tatsache, dass auch eine finale Version von Firebird 3 keine direkten Systemtabellenoperationen erlauben wird.

[Perlsau]

Zitat:

Zitat von tsteinmaurer (Beitrag 1298685)

Ändert nichts an der Tatsache, dass auch eine finale Version von Firebird 3 keine direkten Systemtabellenoperationen erlauben wird.

Und das ist gut so ... :thumb:

[IBExpert]

der eine sieht das so, der andere sieht das anders ....

[Perlsau]

Kann ich nachvollziehen: Wenn ich als Entwickler bei IbExpert nun die ganzen DB-Zugriffe im hauseigenen Datenbank-Manager umschreiben bzw. ergänzen müßte (IbExpert muß ja nun beide Datenbank-Zugriffsmöglichkeiten bereitstellen), wäre ich vielleicht auch nicht allzu erfreut :roll:

[jobo]

Zitat:

Zitat von IBExpert (Beitrag 1298725)

der eine sieht das so, der andere sieht das anders ....

MMh, ist es nicht ein gutes Zeichen, dass ein System erwachsen wird oder sagen wir reif und professionell mit solchen Dingen umgeht. Änderung von Systemtabellen mag mir in der Not vielleicht helfen, aber es lähmt schlimmstenfalls die Weiterentwicklung des Systems, weil zuviel nicht mehr funktionieren könnte, wenn dort dann Umbaumaßnahmen erfolgen würden.
Problematisch ist es natürlich, wenn Dinge unterbunden werden, für die es keinen offiziellem Weg (Interface) gibt.

[IBExpert]

das wir dafür einiges in IBExpert ändern müssen ist das geringste Problem, da steckt eh sehr viel Arbeit in den Erweiterungen für Firebird 3.0

Es gibt aber seit zig Jahren bewährte Verfahren im Firebird Umfeld, die durch diese Entscheidung nicht mehr einsetzbar sind.

Beispiel: Quellcode der SP und Trigger verbergen. Je mehr Business Logik in der DB in SPs und Trigger umgesetzt wurde, um so mehr ist es im Interesse von Unternehmen, Ihre angewandte Business Logik gegenüber Mitbewerbern und anderen zu schützen. In der Vergangenheit war das kein Problem, da man einfach die *SOURCE Spalte in RDB$PROCEDURES und RDB$TRIGGERS überschreiben konnte, da die Ausführung nur die *BLR Inhalte brauchte.

Das geht zukünftig nicht mehr. Quasi zwangsweise Open Source. Wenn Delphi nun den Quelltext deiner Anwendung zwangsweise decompilierbar in die Exe packen würde, dann würdet Ihr das sicherlich auch anders sehen. Wobei das bei VB bzw. .NET Anwendungen nicht so weltfremd ist, aber da versucht man mit Obfuskation die Nutzung schweiriger zu machen.

Es wäre ein einfaches, das den Entwickler durch einen Parameter in der Firebird.conf selbst entscheiden zu lassen, aber das scheint im Moment nicht absehbar zu sein. Bleibt immer noch Hardcore Manpulation der Inhalte mit Tools wie IBExperts Database Inside, mit denen wir das auch zukünftig realisieren können.

[jobo]

[OT]

Zitat:

Zitat von IBExpert (Beitrag 1298803)

..
Es gibt aber seit zig Jahren bewährte Verfahren im Firebird Umfeld, die durch diese Entscheidung nicht mehr einsetzbar sind.
..

Das Problem kann ich verstehen und es ist m.E. tatsächlich etwas anders gelagert als der klassische table alter hack oder so, obwohl die Ausgangssituation aber wohl die gleiche ist. Ich hab keine Kenntnis, wie das "Deprecated" Thema bei fb gehandhabt wird und ob oder welche Anwendergemeinschaften es gibt, aber ist dann da nicht irgendwas in der Kommunikation schief gelaufen? FB 3 ist ja nun schließlich schon eine ganze Weile "unterwegs".
Ist es Ironie oder Politik oder beides, dass ein Open Source System die Anwender zwingt, auch open source zu sein? Klingt allerdings auch etwas nach "selbst die Karten gelegt". Ich hab es ja vorhin schon geschrieben, Aufzuräumen ohne Ersatzschnittstellen/ -verfahren zu schaffen, schafft unnötig Probleme, das sieht aus "Hersteller"perspektive etwas nach Selbstmord aus.
Immherin, wenn Ihr es trotzdem schafft, closed source zu sein, steht Ihr ja nicht schlecht da.

Bin ehrlich gesagt überrascht, dass das (closed source) so ein Thema ist, schließlich geht der Trend bei DB ja angeblich so sehr nach Blackbox bzw. austauschbar. Auch hier im Forum hab ich manchmal den Eindruck, dass Businesslogik in der DB gerade zu zwanghaft vermieden wird. Dazu habe ich immer angenommen, es geht genau darum, eben closed source zu bleiben, auch wenn die Ops Faktoren langsamer oder komplexer sind im Client.
[/OT]

[mkinzler]

Vielleicht wird es dann eine andere Möglichkeit geben, den zusätzlichen abgelegten Quellcode einer SP zu löschen oder zu verschlüsseln.

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1298821)

Vielleicht wird es dann eine andere Möglichkeit geben, den zusätzlichen abgelegten Quellcode einer SP zu löschen oder zu verschlüsseln.

Das wäre naheliegend und wünschenswert, aber closed source ist ja nur ein Beispiel gewesen. Wäre doch schade, wenn soetwas wie firebird wegen solcher Probleme an Verbreitung bzw. Akzeptanz verliert.

[mjustin]

Zitat:

Zitat von IBExpert (Beitrag 1298803)

Das geht zukünftig nicht mehr. Quasi zwangsweise Open Source.

Technisch besteht - da Firebird Open Source ist - im Prinzip die Möglichkeit, die gewünschten Zugriffs/Löschrechte auf die Quelltexte der Stored Procedures zu erhalten.

[tsteinmaurer]

@Holger:

Zitat:

Beispiel: Quellcode der SP und Trigger verbergen. Je mehr Business Logik in der DB in SPs und Trigger umgesetzt wurde, um so mehr ist es im Interesse von Unternehmen, Ihre angewandte Business Logik gegenüber Mitbewerbern und anderen zu schützen. In der Vergangenheit war das kein Problem, da man einfach die *SOURCE Spalte in RDB$PROCEDURES und RDB$TRIGGERS überschreiben konnte, da die Ausführung nur die *BLR Inhalte brauchte.

Das geht zukünftig nicht mehr

Doch, siehe: http://tracker.firebirdsql.org/browse/CORE-4507

Ab dem Zeitpunkt wo das über die Systemtabellen nicht mehr erlaubt ist, soll es eine entsprechende DDL-basierte Lösung geben.

LG

[IBExpert]

ok, gut zu wissen, ist aber bei der zuletzt von mir getesteten aktuellen
beta 1 Version war das auch noch nicht möglich, aber danke für die info

[mkinzler]

Aus meiner sicht grundsätzlich eine gute Sache, nur wenn man bedenkt, wie lange sich FB3 schon verzögert, sollte man eher die angefangenen Features fertigstellen und FB 3 fertigstellen, bevor man immer neue Erweiterungen plant.