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

[DerFrank 15]

so so, da hast du was in Access gefunden was mir noch nie aufgefallen ist. bzw. auf die Idee bin ich, erhlich gesagt, noch nie gekommen.

Ein sehr interessanter Effekt.

Habe es mal abgebildet mit einer Tabell ohne GUID und die andere mit GUID nachgebaut.

interessantes verhalten je nach Abfragenreihenfolge. Hoffe das ich das jetzt verstanden habe was du meinst

 

Hinweis: in der Abfrage 2 befindet sich die Tabelle ohne GUID

 

Ausführung 1:

 

Ausführung 2: Hier ist die Abfrage2 an erster Stelle

 

Wenn du hierzu eine lösung gefunden hast, lass es uns wissen.

Werde hier auch mal schauen was das ist...

 

Bis dann

VG

DerFrank

[DerFrank 15]

hm.. um diesen Ausgabe-Effekt in den Union Querys auszublenden, musst du wohl allen übels in den jeweiliegen Tabellen eine Replikations-ID mit aufnehmen,

die sind dann halt NULL aber dann ist alles wieder im Lot und deine Union's und Join's  sollten dann funktionieren.

 

Ein cast habe ich nicht gefunden aber würde eher die Performance senken...

 

VG

DerFrank

 

 

 

 

[Weingeist 159]

@Zahni: Access nur für Backend: Naja, da hast sicher nicht unrecht. Aber gerade die Backend wäre eigentlich sinnvoll von Anfang an auf SQL. Ist halt ein typisches Access-Projekt, mit was kleinem Angefangen und ständig gewachsen. Sind an die 350 Tabellen und rund 150'000 Zeilen Code (alles objektorientiert, wenig doppeltes). Eine Migration wäre aufgrund vieler automatisierten Workflows mit Barcode-Reader, Waagen usw. extrem aufwändig. Dafür ist die Syntax seit nunmehr 20 Jahren identisch da VB6 und läuft (noch) einfach auf jeder Kiste. Bei .Net wären die laufenden Anpassungen viel Aufwendiger ;)

@Frank: Jetzt hast dus! Hätte noch mehr auf Lager die man normalerweise nie zu Gesicht bekommt. Bis hin zur untersten Ebene mit C++ runtime Fehler wo das ganze Office abschmiert.

Yep, das mit der Reihenfolge hatte ich auch rausgefunden, hilft aber nicht wenn Du deren zwei Qry's hast die jeweils ein einzigartiges Feld haben.

 

Ein halbpatzige Lösungen habe ich, ist aber irgendwie nicht dauerhaft

1. die Abfrage mit einer ge-0-tenGUID speichern (ein allfälliges bereits existierendes Feld mit NULL das Kauderwelsch verursacht muss erst gelöscht und Abfrage gespeichert werden).

2. die 0er-GUID mit NULL ersetzen und wieder speichern

 

Leider habe ich keine Ahnung wo Access die ganzen Quellcodes mit allen Angaben von Abfrage/Formularen/Klassen ablegt damit man es selber reinpatchen könnte. Läuft über irgendwelche XML-Schnittstellen, habe dazu aber leider noch keine Doku gefunden gefunden wie man das selber nutzen könnte. Habe da schon Stunden mit Analysen verbracht.

 

Dann halt die Workarounds die ich teilweise schon genannt habe:

1. In den anderen Tabellen ein Phantomfeld (gefällt mir gar nicht)

2. Eine zusätzliche Tabelle nennen wir sie mal "tbl0union" mit jeweils einem Feld jedes Datentyps und dann mit dieser eine zusätzliche Abfrage erstellen, die man dann zuoberste in die UNION-QRY packt. Dürfte auf die Performance keine Auswirkungen oder höchstens eine positive haben, weil eine Tabelle ohne Datensätze den Feldtyp für sämtliche Felder erzwingt. Sprich keine der Folgeabfragen hat dann ein udefiniertes NULL-Feld mehr. Oder direkt mit Aliasen in die UNION-Qry ist dann aber weniger übersichtlich. (Die gefällt mir eigentlich gar nicht so schlecht, ist mir gestern Abend beim Bier als Gedankenblitz durch den Kopf)

 

 

Bezüglich CAST: Der heisst in Access StringFromGUID und gibt die 36er Variante raus. Für SQL Qry's brauchst z.B. die 45er Variante und in der Software der Einfachheit halber die 32er oder 36er. Habe ich mit einer eigenen StringFromGUID gelöst wo ich die Länge als Argument übergeben kann. Die Arbeit mit GUID's ist eigentlich ziemlich easy. Sie vereinfachen sogar so manches. Solange man eben die Cave-Eats kennt und zu umgehen weiss. Richtig lästig ist nur das keine Verknüpfungen von Main und Subreports direkt möglich sind und eben die gecastete Variante in der zugrundeliegenden Abfrage notwendig ist. Solange man das aber in der letzten Qry macht, ist die Performance gut.

bearbeitet 30. März 2018 von Weingeist

[Weingeist 159]

Kurze Rückmeldung (ist ja so dolles Wetter, kann man auch ohne Verlust arbeiten *g*) - mit der zusätzlichen Tabelle klappt es 1A.

 

1. Tabelle erstellt mit je einem Feld für jeden Datentyp

2. Qry erstellen die gleich aufgebaut ist (Feldnamen, Datentyp) wie die anderen (SELECT tbl0.valGUID AS Feld1_GUID, tbl0.valGUID AS Feld2_GUID tbl0.valCurrency AS Feld3 FROM tbl0)

3. die neue Qry an erster Stelle mit in die UNION SELECT aufnehmen

 

Die Performance ist wie vermutet identisch. Bei nachfolgendem Joins mit Basis der Union-Qry vielleicht sogar ein tick schneller.

 

Die tbl0 verwendete ich vorher schon für Berichte als Datengrundlage. (Access hat bei der Arbeit mit Instanzen und Manipulation am Design/Datengrundlage teilweise die Angewohnheit die Daten doppelt zu laden. Basiert die Datengrundlage auf einer Tabelle ohne Datensätze geht das öffnen von Reports nahezu doppelt so schnell.)