Firebirdforum.de

Nach obiger Beschreibung der 3.x.
Da nun mal 4.0 nicht neu entwickelt wurde sondern eher auf 3.0 basiert, wird das Ergebnis logischerweise nich dem von 2.5ff entsprechen .

Bei mir klappts mit dem Union halt auch korrekt, wenn ich den NULL im 2. Unionblock typisiere. Es scheint eine spezifische Automatisierung von Firebird zu sein, die allerdings nicht SQL-Standard ist. Ähnliches erlebe ich auch beim SQL-Server was dann zu unnötigen Suchereien in den SQL's führt um ein...

Das kann ich natürlich nicht so stehen lassen.
Das Problem ist, dass "select null ..." nicht typisiert ist.
Aber

select cast(null as varchar(1)) from ...

funkioniert. Somit würde man auch kompatibel zu zukünftigen Versionen bleiben.
Zumal man dabei auch noch im SQL-Standard bleibt.

Ja auch das ist korrekt. Nur der Aufwand, die Anwendung auf die Reaktion von Spaltenverschlüsselung umzustellen ist enorm. Was ist das Ergebnis der Verschlüsselung von DateTime? Eben, ein VarBinary. Dies führt beim Lesen ohne Entschlüsselung zum Laufzeitfehler, es sei denn, es gibt dann einen NULL-W...

Die meisten Lösungen dieser Art werden auch ohne Verschlüsselung durch die Anwendung bereits über Berechtigungssysteme durchgeführt. In meiner ERP-Welt gibt es den Begriff des "App-Users". Dieser User hat die ausschließliche Berechtigung an der Datenbank, alle Objekte der DB sind durch Berechtigunge...

Ich glaube, dafür bin ich zu blöd.

Noch ein Nachtrag zu obiger Verschlüsselung:
Welchen Sinn hat denn die Verschlüsselung wenn ich dann auch andere Vergleiche wie >, <, >=, <=, <> oder between nicht per Index optimieren kann?

Was ist PCRE mal ausgesprochen?

BI-Analysen leben von Inidizes. Meine Abfrageanalysen bilden zur Laufzeit die fraglichen Indizes, was dann tatsächlich eine Verschlüsselung ausschließt.

Ich habe bereits mit FB 2.1 wichtige Daten mit den Standard-Encryption-Verfahren verschlüsselt, die mittels Windows-API zur Verfügung stehen. Häufig sind dies XML-Konfigurationen, die ich in einem BLOB komprimiert und verschlüsselt abgelegt habe. Ich sehe da ein Problem von verschlüsselten Daten bei...

Das Thema CTE ist bei allen DB's ein Problem und ist leider der Standard. Die CTE ist nur eine erleichterte Schreibweise ohne an der Funktion etwas zu ändern: select * from TableA A inner join (select * from TableB where <condition1> ) b1 on ... inner join (select * from TableB where <condition2> ) ...

Ich denke mal, das liegt nur an den Berechtigungen für die Tabellen. Prozeduren/Funktionen sind ja separate Objekte die berechtigt werden können. Die Definitin in den Tabellen müssen halt nicht allen Usern zugänglich sein. Klar ist, wenn ich die DB mitnehme und dann als Admin wieder reinschaue, kann...