Access/SQL>Query>bestimmter Fieldtype in berechnetem Feld erzwingen

[Weingeist 159]

Hallo Leute,

 

Gibt es eine Möglichkeit einem berechneten/neuen Feld in einer Qry den Wert NULL eines bestimmten FieldTypes zuzuweisen? Insbesondere GUID?

 

Ausgangslage:

Abfrage 1:

Feld 1: GUID als Autowert

Feld 2: GUID als FK auf Tabelle 2 (also NullWerte oder eben ein ForeignKey auf eine andere Tabelle)

Feld X: Diverse Felder

 

Abfrage 2:

Feld 1: GUID als AutoWert

Feld 2: NULL (Kein zugehöriges Tabellenfeld)

Feld X: Diverse Felder

 

Lege ich nun eine UNION-SELECT über diese beiden bzw. mehrere Abfragen mit gleichem Stil, dann werden die "richtigen" GUID's des Feldes 2 aus Abfrage1 in Kauderwelsch, also Sonderzeichen, chinesische Zeichen usw. umgewandelt.

Ich vermute, dass die Null-Werte von Feld 2 der anderen Abfragen nicht als NULL-Werte von GUID's interpriert werden sondern als Binary oder sonstwas. Dies Obwohl die einzig vorhandenen Werte in Feld 2 - die nicht NULL sind - aus den verschiedenen Abfragen ausschliesslich GUIDs sind.

 

Wie kann man nun Feld 2 in Abfrage 2 verklickern, dass es eben eine GUID mit Wert NULL ist?

 

Einen Work-Around gibt es, indem ich einfach in der Datengrundlage von Abfrage2 in einer Tabelle ein GUID Feld ohne Funktion erzeuge. Wenn es anders geht, fände ich das aber schöner.

 

Grüsse und Danke

[DerFrank 15]

Hallo Weingeist

Muss gestehen, deine frage vielleicht nicht wirklich verstanden zu haben.

Wenn du 2 qry hast und diese mit union "zusammenführst", dann sollte es funktionieren, wenn jeder abfrage die selben feldbezeichnungen haben.

 

Bsp.

Zitat

Select Guid, GuidFk, feldx

From abfrage1

 

Union all

 

Select Guid, NULL as GuidFk, feldx

From abfrage2

 

Oder ich habe deine frage noch nicht verstanden.

Leg doch mal die abfragen vor. Vielleicht ist es dann klaren was du möchtest.

 

Vg

DerFrank

[zahni 554]

Ist das  nun eine Access-DB oder  eine SQL-DB mit  Access-Frontend.

Im 2. Fall  würde immer  eine View  auf  der  SQL-DB versuchen.  Die Felder müssen vom gleichen Datentyp sein.

Ansonsten  mal DDL posten.  So richtig  habe ich  die  Beziehungen auch nicht verstanden.

[DerFrank 15]

Zu dem thema check GUID empty in Sql scha mal hier

https://stackoverflow.com/questions/3092999/check-empty-guid-in-sql

 

[Weingeist 159]

Danke für den Input.

Es ist eine AccessDB in SQL-Server Format (Also ADO als Standard). Ob es beim SQL-Server genauso gehandhabt wird, habe ich ehrlich gesagt gar nicht nachgeprüft.

Grade bemerkt, dass ich in SQL-Server gepostet habe.

 

Im Grunde ist es ganz einfach, versuche es mal in anderen Worten:

1. In Abfrage 1 kommt in Feld 2 eine GUID oder NULL

2. In Abfrage 2 gibt es dieses Feld nicht und wird auch nicht gebraucht, Ich kann also kein Tabellenfeld als Feld 2 definieren sondern definiere das Feld direkt (berechnet). 

 

Syntax Abfrage 1 wäre: "SELECT A.Feld1, A.Feld2 From Tabelle1 AS A"

Syntax Abfrage 2 wäre: "SELECT A.Feld1, NULL AS Feld2 FROM Tabelle2 AS A"

 

Dann UNION SELECT über diese beiden Abfragen. Also (Bewusst zuerst die Abfrage 2, da er da eher auf die Schnautze fällt)

SELECT * FROM Abfrage2

UNION ALL

SELECT * FROM Abfrage1

 

Seltsamerweise hat es auch schon funktioniert. Scheinbar interpretiert er aber in diesem Fall nicht immer identisch oder aber es wird irgendwo ein Feldtyp gespeichert, den man aber nicht ändern kann.

[zahni 554]

Bin mir gerade nicht  sicher, ob es bei einem UNION klug ist beide  Tabellen als "A"  zu benennen. Vielleicht mal bei Abfrage 2 einen anderen Buchstaben probieren. 

[Weingeist 159]

Hi, solange es separate Queries sind, ist das 0 Problem. Kann und darf keines sein. Nur innerhalb der UNION muss man mit den Alias logischerweise unterscheiden. Oder wenn mit Unterabfragen innerhalb der gleichen SQL-Qry gearbeitet wird. Gleiche Alias wird nur zum Problem wenn man innerhalb der Ursprungs-Qry mehrere Feldnamen mit dem gleichen Namen aus unterschiedlichen Tabellen hat, dann macht der Compiler Alias.Feld draus. Dann gibt es Probleme wenn man das Alias in der nächsten Abfrage wieder verwendet.

[zahni 554]

Kann sein. Aber ob Access  das auch weis?  

[Weingeist 159]

Ja klar, Aliase sind ja SQL Basics. Die Syntax von Access (ADO) ist ja eh identisch mit SQL-Server. Wenn das Probleme geben würde, hätte ich mit dem Stück Software ganz andere Probleme.

Das Problem gibt es auch nur mit GUID's. Mit alle anderen Datentypen habe ich diese Probleme nicht. Wenn noch jemand eine Idee hätte wäre das Klasse, ansonsten läuft es dann halt auf ein leeres PhantomFeld hinaus, was ich eigentlich vermeiden wollte.

[zahni 554]

Vielleicht  kannst Du diesen komischen Datentyp nach  Varchar casten.

 

SELECT CAST(MyUniqueIdenfifierColumn AS VARCHAR(36)) FROM MyTable

Was er bei NULL macht, kann ich leider nicht sagen.

 

Edit: Falls Access COALESCE() kennt:

 

Zitat

SELECT A.Feld1, CAST(COALESCE(A.Feld2,'00000000-0000-0000-0000-000000000000') AS VARCHAR(36)) FROM Tabelle2 AS A

Nicht getestet, nur zum Verständnis. Mit COALESCE kannst Du NULL-Werte mit einem zum Datentype passenden anderen Wert  belegen.

bearbeitet 29. März 2018 von zahni

[Weingeist 159]

Die richtigen GUID's müsste ich dann auch umwandeln damit es so überhaupt klappt. Wenn aber GUID's in CHAR umgewandelt werden, wird die Performance unterirdisch wenn nachher noch ein Join gemacht werden muss. Kann man komplett knicken. Muss ich an manchen Stellen zwar auch machen, aber nur wenn ein Formular oder Report die GUID nicht selber wandeln kann und das ist nur bei der Verlinkung mit SubReports/Forms der Fall. Dann gibt es das aber immer als zusätzliches Feld und nicht anstatt.

 

Eine ge-0-te GUID ( {guid {00000000-0000-0000-0000-000000000000}} ) funktioniert übrigens.  Dann sind aber allfällige Joins auf eine grössere UNION SELECT Qry wieder sehr viel langsamer als wenn es wirklich NULL Werte sind. Diese werden bei JOINS ignoriert.

Die realen Abfragen sind leider bei weitem nicht so trivial gestrickt wie mein Reproduzier-Muster hier.

[zahni 554]

Wie im Beispiel wird  eigentlich  erst im Resultset  "gecastet". Der Join  läuft  mit  den originalen  Datentypen.

 

BTW: Wozu muss man eigentlich diese GUIDs  nehmen. Als PK reicht BIGINT  (kann Access nicht).

bearbeitet 29. März 2018 von zahni

[DerFrank 15]

Hi

ich verstehe es immer noch nicht was du meinst Wingeist...

habe mach was zusammen geschustert.

Die Quelle liegt auf dem SQL Server.  Die Quelle besitzt ein Feld ww_RezeptID und ist vom Type (GUID)
In der Quelle sind 2 Einträge, bei denen die GUID NULL ist. (siehe screeshoot)

In Access habe ich zwei Abfragen: Abfrage1 und Abfrage2.

In Abfrage1. In Abfrage1 wird  Feld ww_RezeptID auf "is Null" gefiltert und in Abfrage2 auf "Not is Null".

Eine Union erstellt und ich erhalte alles was ich sehen will... hmmm... da brauche ich nichts casten oder sonstiges.

 

 

VG
DerFrank

 

[Weingeist 159]

@Zahni: Ja klar, aber wenn ich nachher die UNION Qry wieder joinen muss ist eben essig. Könnte ich natürlich auch in den Zugrundeliegenden Abfragen bereits erledigen, ist aber deutlich langsamer (knapp 30%) als wenn ich erst auf Basis der UNION-Qry einen Join laufen lasse und auch die Komplexität/Wartung der zugrundeliegenden Abfragen sowie die Übersicht wird um ein vielfaches mühsamer.

 

Warum GUID: Die ganze Anwendung basiert mehrheitlich auf GUID's. Hat verschiedene Gründe warum das im Endeffekt deutlich besser ist. Insbesondere dient es der wirkungsvollen Datenkonflikt-Vermeidung wenn viele Clients auf die gleiche Backend-Zugreifen. Man hat ja keine SP's in Access und muss alles in der Software abbilden. Die meisten Probleme die man mit Multi-User und Access haben kann, treten mit GUID's als Keys in Bearbeitungstabellen gar nicht erst auf.
Auch kann man die Write-Zeiten auf ein Minimum reduzieren weil Datensätze inkl. PK's erstmal nur im RAM der Clients liegen und dann gesammelt geschrieben werden = Weniger gleichzeitige Writes = Vielfaches der Performance und keine Daten-Konflikte. Ein weiterer Punkt sind externe Daten. Die können generiert und ohne Anpassung exportier/importiert werden. Ein Abgleich ist mit GUID's als PK/FK ist viel einfacher als mit einfachen Zahlen. Einfache Zahlen kann eigentlich nur ein Server zuverlässig generieren, eine GUID auch problemlos ein Client.

 

@Der Frank: Solange die zugrundeliegende Tabelle ein GUID-Feld hat, welches wiederum in manchen Datensätzen den Wert NULL und in manchen Datensätzen einen ForeignKey auf eine andere Tabelle aufweist, ist alles kein Problem. Wenn aber eine der Queries dieses Feld nicht in einer Tabelle hat, wird es zum Problem.

Siehe dazu die SQL-Syntax der Abfragen meiner letzten Antwort.  --> (SQL-Syntax: Feld2 AS NULL)

bearbeitet 29. März 2018 von Weingeist

[zahni 554]

Access nimmt auch maximal als Backend ;-).

Unsre Entwickler kennen diesen Datentyp nicht...