Jump to content

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


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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 von zahni
Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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.

 


image.thumb.png.282c832eeeec228cc4aad2d7ad94c125.png

 

VG
DerFrank

 

Link zu diesem Kommentar

@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 von Weingeist
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...