UniDAC Firebird Roles Casesensitive

[grl]

Tag!

Mit Firebird SQL Dialect 3 können Roles auf Case-Sensitive sein wie Tabellen- und Feldnamen auch.
Mit UniDAC (hier: 8.1.2) funktioniert das aber nicht.

Firebird 3:

Code:

CREATE ROLE "Testrole";
GRANT ALL ON "Testtable" TO ROLE "Testrole";

und in meinem Quellcode:

Code:

DB.SpecificOptions.Values['Role']:='"Testrole"';

Das funktioniert nicht, der User hat keine Rechte und CURRENT_ROLE in Firebird ist NONE.



Wenn ich zu Roles ohne Anführungszeichen wechsle gehts:
Firebird 3:

Code:

CREATE ROLE TESTROLE;
GRANT ALL ON "Testtable" TO ROLE TESTROLE;

und in meinem Quellcode:

Code:

DB.SpecificOptions.Values['Role']:='TESTROLE';

Das geht wie erwartet.


Aber die Roles sind von einer anderen Applikation als case sensitive vorgegeben - also muss das sein.
Weiß jemand wie das mit UniDAC geht?


Danke
Luggi

[jobo]

Die Schreibweise mit den doppelten Anführungszeichen halte ich für falsch.
DB haben ihre (meist etwas) unterschiedlichen Eigenarten, um so etwas wie Case Sensivity und den ganzen Kram zu ermöglichen (Sonderzeichen aller Art, Leerzeichen, Emoticons)
Doppelte Anführungszeichen sind dafür nicht ungewöhnlich.

Wie eine Client Lib damit umgeht, ist noch was anderes. Ich hab keinen Zugriff auf die von Dir genannte.
Mich wundert es nicht, dass Dein Versuch nicht funktioniert.

Auf den Punkt:
Ein "andere App", die solche Vorgaben macht, kann höchstens logische Rollen meinen und die physischen einer DB.
Ich würde ein Mapping anlegen, dass den Zusammenhang definiert und mit den klassischen Mitteln arbeiten.

[grl]

Zitat:

Zitat von jobo (Beitrag 1462394)

Die Schreibweise mit den doppelten Anführungszeichen halte ich für falsch.
DB haben ihre (meist etwas) unterschiedlichen Eigenarten, um so etwas wie Case Sensivity und den ganzen Kram zu ermöglichen (Sonderzeichen aller Art, Leerzeichen, Emoticons)
Doppelte Anführungszeichen sind dafür nicht ungewöhnlich.

Die doppelten Anführungszeichen sind richtig. Der Firebird-SQL Dialect 3 macht das so. z.B. würde ein Select dann so aussehen:

Code:

SELECT "Feldname", "FeldName", "feldname" FROM "Tabelle";

und du hättest drei verschiedene Felder gewählt.
Das gleiche gilt für Roles. Wird ein externes Datenbank-Tool wie z.B. RedAdmin verwendet und man gibt die Roles genau so an wie ich das mache (also "Role") dann geht alles wunderbar.

Zitat:

Zitat von jobo (Beitrag 1462394)

Auf den Punkt:
Ein "andere App", die solche Vorgaben macht, kann höchstens logische Rollen meinen und die physischen einer DB.
Ich würde ein Mapping anlegen, dass den Zusammenhang definiert und mit den klassischen Mitteln arbeiten.

Bei einem Mapping würden aber die (im Programm sichtbaren) Roles nicht gleich sein wie im anderen Programm.
Lieber wäre mir die Roles einfach so zu benutzen wie vorgesehen und nicht einen offensichtlichen Bug (bei mir oder bei UniDAC) mit einer Krücke zu umgehen.

Gruß
Luggi

[jobo]

Zitat:

Zitat von grl (Beitrag 1462396)

Zitat:

Zitat von jobo (Beitrag 1462394)

Die Schreibweise mit den doppelten Anführungszeichen halte ich für falsch.
DB haben ihre (meist etwas) unterschiedlichen Eigenarten, um so etwas wie Case Sensivity und den ganzen Kram zu ermöglichen (Sonderzeichen aller Art, Leerzeichen, Emoticons)
Doppelte Anführungszeichen sind dafür nicht ungewöhnlich.

Die doppelten Anführungszeichen sind richtig. Der Firebird-SQL Dialect 3 macht das so. z.B. würde ein Select dann so aussehen:

Code:

SELECT "Feldname", "FeldName", "feldname" FROM "Tabelle";

und du hättest drei verschiedene Felder gewählt.

Ja, in SQL ist es so richtig, es funktioniert ja auch. Ich hab mich undeutlich ausgedrückt, die Übernahme der Schreibweise in Delphi halte ich für mindestens fraglich. Und da kann man spekulieren oder in den Referenzen schauen, vielleicht ist es kein Bug, sondern wird einfach nicht unterstützt.

Ebenso fraglich scheint mir der Wunsch, Datenbankobjekte so nennen zu wollen, wie ein drittes Programm es "vorgibt".
Die Schreibweise von Objekten ist eine Implementierungsfrage, ob es um Rollen oder um Tabellen geht. Es handelt sich nicht um Daten, über die man die volle Hoheit haben sollte.
Sinn macht das eigentlich nur, wenn man versucht, eine Datenbank-Migration plant und einem bestehenden Programm eine andere DB unterjubeln will.

Was spricht gegen ein Mapping? Du bennenst Deine Rollen optisch, aus Nutzerperspektive genau so wie gewohnt und verwendest intern was anderes. Es bietet m.E. nur Vorteile, man könnte von da an die Rollenbezeichnungen bspw. übersetzen.

[grl]

Zitat:

Zitat von jobo (Beitrag 1462400)

Ja, in SQL ist es so richtig, es funktioniert ja auch. Ich hab mich undeutlich ausgedrückt, die Übernahme der Schreibweise in Delphi halte ich für mindestens fraglich. Und da kann man spekulieren oder in den Referenzen schauen, vielleicht ist es kein Bug, sondern wird einfach nicht unterstützt.

Es ist ein Bug - bei mir oder UniDAC. Die Referenzen sind eindeutig: mit double quotes.
Und mit anderen Tools funktioniert es - übrigens auch mit anderen Access-Components wie z.B. UIB.
Und bevor der Vorschlag kommt: Das ganze Ding von UniDAC auf was anderes umzustellen steht nicht zur Debatte - der Aufwand wäre definitiv zu groß.

Zitat:

Zitat von jobo (Beitrag 1462400)

Ebenso fraglich scheint mir der Wunsch, Datenbankobjekte so nennen zu wollen, wie ein drittes Programm es "vorgibt".
Die Schreibweise von Objekten ist eine Implementierungsfrage, ob es um Rollen oder um Tabellen geht. Es handelt sich nicht um Daten, über die man die volle Hoheit haben sollte.
Sinn macht das eigentlich nur, wenn man versucht, eine Datenbank-Migration plant und einem bestehenden Programm eine andere DB unterjubeln will.

Die Datenbank ist aber so und daher so zu nutzen. Und nein, in ganz vielen Fällen hat man nicht die volle Hoheit über ein Datenbank-Design sondern muss nehmen was vorhanden ist.

Zitat:

Zitat von jobo (Beitrag 1462400)

Was spricht gegen ein Mapping? Du bennenst Deine Rollen optisch, aus Nutzerperspektive genau so wie gewohnt und verwendest intern was anderes. Es bietet m.E. nur Vorteile, man könnte von da an die Rollenbezeichnungen bspw. übersetzen.

Daß ich nicht einen Bug mit einer Krücke umgehe. Die Rollen sind so definiert, es ist Standardkonform, also möchte ich sie so nutzen.
Bugs nicht zu suchen und zu fixen sondern zu umgehen ist meiner Meinung nach extrem schlechter Stil und verantwortlich für einen ganzen Haufen Schrott-Software da draussen.


Die Frage bleibt also: Weiß jemand wie man UniDAC beibringt eine Role mit Anführungszeichen zu übernehmen?

Danke
Luggi

[hstreicher]

Aktuell ist die Unidac 8.1.3 , schon mal ausprobiert ?

[himitsu]

Zitat:

Zitat von jobo (Beitrag 1462394)

Zitat:

Delphi-Quellcode:

DB.SpecificOptions.Values['Role']:='"TESTROLE"';

Die Schreibweise mit den doppelten Anführungszeichen halte ich für falsch.

Jupp, wenn die Klasse dort z.B. mit Parameter arbeitet oder die Eingaben ordentlich maskiert (code-injection), dann gehören bei diesem String die " mit zum Namen, den es so aber nicht gibt.

Hast denn mal geschaut, wie das DB.SpecificOptions.Values in der DB ankommt? (SQL-Log, Activities, ...)

Die Möglichkeiten, die ich dann sehen würde:
* direkt via SQL-Statement die Rolle in der Connection setzen (AfterConnect)
* oder es müsste an der Klasse irgendwo ein Property/Option geben, wo man seine Eingaben als case-sensitive markiert (falls der hersteller hier z.B. mit Lowercase bissl nachgeholfen hat)

[jobo]

ot

Zitat:

Zitat von grl (Beitrag 1462402)

Bugs nicht zu suchen und zu fixen sondern zu umgehen ist meiner Meinung nach extrem schlechter Stil und verantwortlich für einen ganzen Haufen Schrott-Software da draussen.

Volltreffer:
Du sagst es sei ein Bug. Wenn Du Dir so sicher bist, muss er sich ja bei ComponentSource finden. Wenn nicht meldet man ihn.
"Andere Software kann das" ist übrigens kein Hinweis darauf, dass es sich bei der vorliegenden Software um einen Bug handelt. Ich sprach von "nicht implementiert".

Ich habe hier noch nie von jemand verlangt, alles neu zu machen. "Verlangt" ist eh Quatsch, es sind meistens wohlfeile Vorschläge, die unrealistisch sind. Es geht idR um pragmatische Alternativen. Angenommen es ist ein Bug, ist doch einfach die Frage, wie schnell Du als Kunde einen Fix erhälst. Ein Workaround ist demnach nur bedingt eine Stilfrage.

Apropos Stil:
Bei Objektnamen (in der DB und anderswo) auf die Möglichkeit zu verzichten, nationale Spracheigenarten zu verwenden, halte ich nach wie vor für einen sehr guten Weg, Problemen aus dem Weg zu gehen (ohne Funktionseinbuße).

Fachlich bleibe ich dabei, ich "streite" mich nicht mit einer anderen Anwendung um Implementierungsdetails bzw. gebe die vor. Eine Rolle zu kopieren und anders zu benennen wäre eine sehr unaufwändige Lösung, vielleicht beherrscht Firebird auch Rollendefinitionen, die auf Rollen basieren...

[grl]

Zitat:

Zitat von hstreicher (Beitrag 1462406)

Aktuell ist die Unidac 8.1.3 , schon mal ausprobiert ?

Noch nicht. Allerdings geben weder Changelog noch ein diff des Sourcecodes irgendein Anzeichen dafür, daß in diesem Bereich etwas geändert wurde.

Zitat:

Zitat von himitsu (Beitrag 1462408)

Hast denn mal geschaut, wie das DB.SpecificOptions.Values in der DB ankommt? (SQL-Log, Activities, ...)

Da hab ich leider keine Möglichkeit gefunden. Die role muss im Verbindungsaufbau gesetzt werden und da hab ich keine Möglichkeit gefunden den zu belauschen. Auch mit tcpdump und wireshark nicht.

Zitat:

Zitat von himitsu (Beitrag 1462408)

* direkt via SQL-Statement die Rolle in der Connection setzen (AfterConnect)

Da hab ich auch keine Möglichkeit gefunden - auch nach langer Analyse des Verbindungsprozesses im Sourcecode von UniDAC via Debugger. Leider ist der Code aufgrund der Unterstützung so vieler verschiedener Datenbanken ziemlich komplex und damit deutlich schwerer zu debuggen als z.B. UIB.
Und die Role nachträglich - also bei aufrechter Connection - zu ändern wird erst ab Firebird 4 unterstützt werden.

Zitat:

Zitat von himitsu (Beitrag 1462408)

* oder es müsste an der Klasse irgendwo ein Property/Option geben, wo man seine Eingaben als case-sensitive markiert (falls der hersteller hier z.B. mit Lowercase bissl nachgeholfen hat)

Hab ich auch nicht gefunden. Wenn man den SQLDialect richtig setzt werden SQL-Strings korrekt gebildet und behandelt. Nur eben die Role nicht.

Ich habe schon einen Support-Case bei DevArt aufgemacht. Aber auch dort ist vermutlich Wochenende... Aber das kennen ja sicher noch andere, daß genau dann, wenn beim Support Wochenende ist die Arbeit hier trotzdem unter den Nägeln brennt. Und dummerweise hab ich mit das Roles-Thema für ziemlich am Ende des Projektes aufgehoben...

Danke
Luggi

[grl]

Für alle die später mal auf diesen Thread stossen:

Es war ein Bug in UniDAC. Devart hat einen Hotfix zur Verfügung gestellt - damit geht es wie gewünscht.

Gruß
Luggi