UniDAC Firebird Roles Casesensitive

[jobo]

Zitat von grl:

Zitat von 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.

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 von jobo:

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 von jobo:

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 von jobo:

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 ?