<\/p>\n
Wer einen Onlineshop verwendet, verwaltet in der Regel auch die Kunden- und Bestelldaten auf dem Internetserver, auf dem sich die Shopsoftware befindet. Dennoch gibt es verschiedene Gründe, sich diese Daten auch auf dem Desktop verfügbar zu machen – und zwar nicht nur über das jeweilige Shop-Backend. Die Daten wollen schließlich weiterverwendet werden, beispielsweise für die Vorbereitung der Lieferung, den Rechnungsversand, die Prüfung des Rechnungseingangs et cetera. Leider liefert das Shopsystem die Daten meist nicht in der gewünschten Struktur. Schauen wir uns also anhand des Shopsystems Shopware an, wie wir uns die Daten gefügig machen.<\/b><\/p>\n
Shopware ist eines der moderneren Shopsysteme. Ein Beispiel für einen Shop auf Basis dieses Systems ist etwa der Shop des André Minhorst Verlags<\/b>, in dem Sie möglicherweise auch das Abonnement zu diesem Magazin bestellt haben (shop.minhorst.com<\/b>). Da ich also selbst mit diesem System arbeite, ist es naheliegend, dieses Shopsystem als Beispiel für diesen Artikel heranzuziehen.<\/p>\n
Zugriff verschaffen<\/b><\/p>\n
Die optimale Lösung für den Zugriff auf die Daten des Shops erfolgt per ODBC. Wenn die Datenbanksoftware auf dem Server dafür freigeschaltet ist, können Sie die Tabellen des Shopsystems direkt in eine Datenbank auf dem lokalen Rechner einbinden.<\/p>\n
Sie arbeiten dann mit den verfügbaren Tabellen, als ob diese sich direkt in der Datenbank befinden – mit dem Unterschied, dass der Zugriff vielleicht an der einen oder anderen Stelle etwas langsamer erfolgt.<\/p>\n
Für den Zugriff sollte Ihr Provider die entsprechenden Einstellungen vornehmen und folgende Daten liefern können:<\/p>\n
Wenn Ihnen diese Informationen vorliegen, können Sie die Verbindung über den entsprechenden Assistenten von Access herstellen – wie im Beitrag RDBMS-Tabellen manuell verknüpfen <\/b>(www.access-im-unternehmen.de\/973<\/b>). Oder Sie erledigen dies wie in den Beiträgen RDBMS-Tools: Verbindungen verwalten <\/b>(www.access-im-unternehmen.de\/976<\/b>) und RDBMS-Tools: Tabellen verknüpfen <\/b>(www.access-im-unternehmen.de\/977<\/b>) beschrieben mit zwei komfortablen Formularen.<\/p>\n
Diese können Sie auch in Form eines Add-Ins einbinden – siehe RDBMS-Tools als Add-In <\/b>(www.access-im-unternehmen.de\/978<\/b>). In diesem Beitrag nutzen wir in diesem Fall die letztere Variante.<\/p>\n
Wenn Sie das Add-In aus dem genannten Beitrag installiert haben, fügen Sie mit dem Start des Add-Ins automatisch die für den Zugriff nötigen Tabellen tblVerbindungszeichenfolgen <\/b>und tblTreiber <\/b>an. Sie brauchen dann nur noch zunächst das Add-In RDBMS-Tools: Verbindungen verwalten <\/b>aus dem Ribbon-Menü Datenbanktools|Add-Ins|Add-Ins <\/b>auszuwählen. Dort geben Sie wie in Bild 1 die Verbindungsdaten ein und schließen den Dialog wieder.<\/p>\n
![\"Einstellen](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_001.png\")
<\/p>\n
Bild 1: Einstellen der Verbindungseigenschaften<\/span><\/b><\/p>\n Danach rufen Sie aus dem gleichen Ribbon-Menü den Eintrag RDBMS-Tools: Tabellen verknüpfen <\/b>auf. Hier wählen Sie nun die soeben erstellte Verbindungszeichenfolge aus dem oberen Kombinationsfeld aus und klicken dann auf Aktualisieren<\/b>. Das Formular zeigt nun alle Tabellen der gewählten Datenbank an.<\/p>\n Nach kurzem Durchsehen der Tabellen scheint klar zu sein, dass sich die Kundendaten in Tabellen befinden, die das Schlüsselwort User <\/b>enthalten – zumindest gibt es keine Tabellen etwa namens Customer <\/b>oder dergleichen. Also filtern wir das Listenfeld durch Eingabe des Wortes User <\/b>in das Textfelder Filter <\/b>und erhalten so die gesuchten Tabellen (s. Bild 2).<\/p>\n Bild 2: Herstellen der Verknüpfungen<\/span><\/b><\/p>\n Wir markieren die Tabellen, die für uns interessant sein könnten, und erstellen durch einen Mausklick auf die Schaltfläche Tabellen verknüpfen <\/b>entsprechende Verknüpfungen.<\/p>\n Wir wollen die Kunden inklusive Liefer- und Rechnungsanschrift in die Zieldatenbank importieren. Dazu schauen wir uns die Tabellen zunächst genauer im Beziehungsfenster an. Von den importierten Tabellen bleiben drei übrig, von denen eine die Grunddaten der Kunden enthält, eine die Rechnungsdaten und eine die Lieferdaten.<\/p>\n Um uns dies später beim Erstellen von Abfragen sparen zu können, fügen wir den Tabellen zwei Verknüpfungen hinzu (s. Bild 3). <\/p>\n Bild 3: Für den Kunden-Import interessante Tabellen<\/span><\/b><\/p>\n Als Nächstes müssen wir herausfinden, wie die Daten in den drei Tabellen gespeichert werden. Im Shop des André Minhorst Verlags beispielsweise gibt man zunächst eine nicht näher spezifizierte Adresse ein (s. Bild 4). Darunter findet sich dann die Möglichkeit, anzugeben, dass die Lieferadresse von der Rechnungsadresse abweicht. Klickt man diese Option an, ist klar, dass die zuerst eingegebene Adresse der Rechnungsadresse entspricht, denn es erscheint nun ein eigener Bereich zur Eingabe der Lieferadresse. Gibt man zwei verschiedene Adressen für die Lieferung und die Rechnung an, ist der Fall also offensichtlich klar. Aber wo landen die Daten, wenn der Benutzer nur einen Satz Adressdaten einträgt – in der Tabelle s_user_billingaddress <\/b>oder s_user_shippingaddress<\/b><\/p>\n Bild 4: Eingabe der Kundendaten im Shop<\/span><\/b><\/p>\n Zielfelder für Adressdaten prüfen<\/b><\/p>\n Oder trägt die Shopsoftware die Adresse einfach gleich für beide Adressen ein Wir werden nicht um eine Prüfung dieses Sachverhalts herumkommen. Also erstellen wir eine neue Abfrage, welche die drei Tabellen s_user<\/b>, s_user_shippingaddress <\/b>und s_user_billingaddress <\/b>aufnimmt. Die soeben im Beziehungen-Fenster hinzugefügten Beziehungen werden praktischerweise direkt in den Abfrageentwurf übernommen. Dann ziehen wir die benötigten Felder aus den drei Tabellen in das Entwurfsraster. Aus der Tabelle s_user <\/b>entnehmen wir dabei nur die Felder id <\/b>und email<\/b>, aus den beiden übrigen Tabellen die üblichen Adressfelder (s. Bild 5).<\/p>\n Bild 5: Abfrage mit Liefer- und Rechnungsfeldern<\/span><\/b><\/p>\n Ein Wechsel in die Datenblattansicht liefert dann interessanterweise nicht den soeben frisch im Shop angelegten Datensatz. Warum das nicht Es kann eigentlich nur einen Grund geben: Da wir die Verknüpfungen mit in die Abfrage übernommen haben, kann diese nur Datensätze liefern, für die auch in allen beteiligten Tabellen Daten vorliegen.<\/p>\n Dies bedeutet also, dass mindestens eine der Tabellen keine Daten enthält und die eingebene Adresse wohl entweder nur in der Tabelle s_user_shipping-address <\/b>oder —-s_-user_bil-lingaddress <\/b>gelandet ist. Um dies zu prüfen, passen wir die Abfrage nochmals an, damit diese immer alle Datensätze anzeigt – unabhängig davon, ob alle Tabellen Daten enthalten. Klicken Sie dazu doppelt auf den ersten der beiden Verknüpfungspfeile und stellen Sie die nun erscheinenden Verknüpfungseigenschaften so ein, dass alle Datensätze der Tabelle s_user<\/b> angezeigt werden und nur die passenden Datensätze aus der jeweils verknüpften Tabelle (s. Bild 6).<\/p>\n <\/p>\n Bild 6: Einstellen der Verknüpfungseigenschaften<\/span><\/b><\/p>\n Anschließend erscheint der neu angelegte Kunde auch in der Abfrage in der Datenblattansicht. Dort wird schnell offensichtlich, dass eine gemeinsame Adresse für Lieferung und Rechnung einfach in der Tabelle s_user_billingaddress <\/b>landet (s. Bild 7).<\/p>\n Bild 7: Abfrage mit den Adressdaten eines zu Testzwecken angelegten Kunden<\/span><\/b><\/p>\n Abfrage an Zieltabelle anpassen<\/b><\/p>\n Nun folgt eine sehr interessante Aufgabe: Wir wollen die Abfrage qryUserBillingShipping<\/b> so anpassen, dass sie genau der Datenstruktur der Zieltabelle in unserer Kundenverwaltung entspricht.<\/p>\n Dazu werfen wir nun zunächst einen Blick auf den Entwurf der Kundentabelle. Diese kann natürlich bei Ihnen oder bei Ihren Kunden ganz anders aussehen – aber es geht ja auch nur darum, beispielhaft den Import von Kundendaten von einem System ins andere zu demonstrieren.<\/p>\n Der Entwurf der Tabelle tblKunden<\/b> sieht etwa wie in Bild 8 aus. Hier gibt es also einen Satz von Adressdaten, die, sofern keine separate Rechnungsadresse angegeben wird, als Liefer- und Rechnungsadresse genutzt wird.<\/p>\n Bild 8: Zieltabelle für den Import der Kundendaten<\/span><\/b><\/p>\n Liegt hingegen eine Rechnungsadresse vor, nehmen die einfachen Felder die Lieferadresse auf.<\/p>\n Dummerweise ist es in den Kundentabellen im Shop genau andersherum: Dort wird die zusätzliche Adresse als Lieferadresse gespeichert. Aber das ist kein Problem – wir sind ja anpassungsfähig.<\/p>\n Verschiedene Fälle<\/b><\/p>\n Der einfachste Fall ist, dass der Kunde im Shop nur eine einzige Adresse als Liefer- und Rechnungsadresse angegeben hat. In diesem Fall können wir die Felder aus der Tabelle s_user_billingaddress <\/b>einfach in die Felder Firma<\/b>, AnredeID<\/b>, Vorname <\/b>et cetera der Tabelle tblKunden <\/b>importieren.<\/p>\n Wenn der Kunde allerdings auch noch eine abweichende Adresse angegeben hat, sollen die Werte der Tabelle s_user_billingaddress <\/b>in den Feldern Firma_Rechnung<\/b>, AnredeID_Rechnung<\/b>, Vorname_Rechnung <\/b>und so weiter landen und die Werte der Tabelle s_user_shippingaddress <\/b>in den Feldern Firma<\/b>, AnredeID<\/b>, Vorname <\/b>et cetera.<\/p>\n Wir müssen also in der Abfrage, welche die Felder wie in der Zieltabelle abbilden soll, abfragen, ob die Tabelle s_user_shipping <\/b>vorhanden ist, und die Daten dann mit entsprechenden IIf<\/b>-Statements variieren.<\/p>\n Wie aber wollen wir die Abfrage überhaupt so gestalten, dass diese wie die Tabelle tblKunden <\/b>aufgebaut ist Das ist einfach: Wir benennen die entsprechenden Felder beziehungsweise die Ausdrücke, welche die Werte liefern, entsprechend den Feldern der Tabelle tblKunden<\/b> um.<\/p>\n Länder zur Abfrage hinzufügen<\/b><\/p>\n Die Abfrage qryUserBillingShipping <\/b>enthält das Feld countryID <\/b>der beiden Tabellen s_user_shippingaddress <\/b>und s_user_billingaddress<\/b>. Dieses liefert nur eine Zahl, da dieses Feld mit einer Lookuptabelle namens s_core_countries <\/b>verknüpft ist, welche die Länderbezeichnungen zu den Zahlenwerten aus countryID <\/b>liefert. Diese würden wir natürlich gern noch in die Abfrage einbeziehen, um nicht alle Ländercodes separat per verschachteltem IIf <\/b>ermitteln zu müssen.<\/p>\n Wenn wir diese Tabelle wie in Bild 9 zweimal zur Abfrage hinzufügen, meldet Access allerdings einen Fehler: Die SQL-Anweisung konnte nicht ausgeführt werden, da sie mehrdeutige äußere Verknüpfungen enthält. […]<\/b><\/p>\n Bild 9: Erweitern der Abfrage um Länderdaten<\/span><\/b><\/p>\n Dies können wir nur mithilfe zweier Hilfsabfragen abändern, die jeweils eine der Tabellen s_user_billingaddress <\/b>oder s_user_shippingaddress <\/b>sowie zusätzlich die Tabelle s_core_countries <\/b>enthält.<\/p>\n Dies sieht für die Tabelle s_-user_bil-lingaddress<\/b> etwa wie in Bild 10 aus. Auf die gleiche Weise erstellen wir noch eine Abfrage namens qry_s_user_shippingaddress_with_country<\/b>.<\/p>\n Bild 10: Zusammenfassung von Rechnungsadressen und Land<\/span><\/b><\/p>\n Beide fügen wir dann zur Abfrage qryUserBillingShipping <\/b>hinzu, aus der wir natürlich zuvor die beiden Tabellen s_user_shippingaddress <\/b>und s_user_billingaddress <\/b>entfernen.<\/p>\n Beide Abfragen enthalten dann alle Felder der Tabelle s_user_shippingaddress <\/b>beziehungsweise s_user_billingaddress <\/b>sowie das Feld country <\/b>der Tabelle s_core_countries<\/b>.<\/p>\n Die Abfrage qryUserBillingShipping<\/b> sieht nun wie in Bild 11 aus. Für die Verknüpfungen stellen Sie wieder die gleichen Eigenschaften wie zuvor ein, damit die Abfrage immer alle Datensätze der Tabellen s_user <\/b>enthält, auch wenn s_user_shippingaddress <\/b>nicht zugeordnet ist.<\/p>\n Bild 11: Abfrage-Datenquellen, jetzt mit integrierten Länderangaben<\/span><\/b><\/p>\n Wenn Sie nun in die Datenblattansicht wechseln, um sich das Ergebnis anzusehen, erhalten Sie allerdings eine Fehlermeldung, die nur wenig aussagekräftig ist.<\/p>\n Nach längerem Experimentieren kam jedoch heraus, dass man die Verknüpfungen in der umgekehrten Reihenfolge zusammenfassen muss, wenn man zu s_user<\/b>, s_user_shippingaddress <\/b>und s_user_billingaddress <\/b>auch noch die Daten der Tabelle s_core_countries <\/b>hinzufügen möchte.<\/p>\n Also starten wir wieder mit der ursprünglichen Version, welche die Tabellen s_user<\/b>, s_user_billing-address <\/b>und s_user_shipping-address <\/b>enthält und speichern diese unter dem Namen qryUserBillingShipping<\/b>. Dann erstellen Sie eine weitere neue Abfrage namens qryUserBillingShipping_With_Country<\/b>, der Sie qryUserBillingShipping <\/b>hinzufügen sowie zweimal die Tabelle s_core_countries<\/b>. Diese Tabelle verknüpfen Sie dann einfach über das Feld id <\/b>mit den Feldern countryID <\/b>der Tabellen s_user_billingaddress <\/b>und s_user_shippingaddress <\/b>aus der Abfrage qryUserBillingShipping<\/b> (s. Bild 12).<\/p>\n Bild 12: Benutzerdaten mit Ländern, funktionierende Version<\/span><\/b><\/p>\n Die Feldbezeichnungen in der Abfrage qryUserBillingShipping <\/b>wirken jetzt allerdings etwas unhandlich. Dies können Sie leicht ändern, indem Sie die zugrunde liegende Abfrage öffnen, dort zum Beispiel auf die Tabelle s_user_billingaddress <\/b>klicken und im Eigenschaftsfenster unter Alias einen kürzeren Namen eintragen. Wir wollen es so kurz wie möglich machen und verwenden schlicht b <\/b>für billing<\/b>.<\/p>\n Für die Tabelle s_user_shippingaddress <\/b>verwenden wir den Buchstaben s<\/b>. In der Datenblattansicht kommt die Abfrage qryUserBillingShipping_With_Country<\/b> nun schon wesentlich schlanker daher (s. Bild 13).<\/p>\n Bild 13: Tabellennamen in abgekürzter Form<\/span><\/b><\/p>\n Felder zuordnen<\/b><\/p>\n Damit haben wir nun eine Abfrage mit allen Daten, die in der Tabelle tblKunden<\/b> landen sollen. Nun müssen wir nur noch die richtige Zuordnung vornehmen – und zwar in Abhängigkeit davon, ob ein Wert im Feld Salutation <\/b>der Tabelle s_user_shippingaddress <\/b>vorliegt.<\/p>\n Dazu können wir durchaus schon mal alle Felder der Abfrage qryUserBillingShipping <\/b>plus die beiden Country<\/b>-Felder in das Entwurfsraster der Abfrage ziehen.<\/p>\n Dann folgt die eigentliche Denkarbeit: Wir müssen der Abfrage nun für jedes Feld der Zieltabelle, also der weiter oben bereits vorgestellten tblKunden<\/b>, ein Feld hinzufügen, das aus dem Feldern der Datenherkunftstabelle entsprechende Ausdrücke zum Füllen von tblKunden<\/b> formuliert. In Bild 14 sehen Sie beispielsweise das Feld Firma <\/b>mit dem folgenden Ausdruck:<\/p>\n Bild 14: Abfrage mit auf die Zieltabelle gemappten Ausdrücken<\/span><\/b><\/p>\n Dieser Ausdruck prüft, ob der Wert des Feldes salutation <\/b>der Tabelle s <\/b>(abgekürzt für s_user_shipping-address<\/b>) Null ist. Ist das der Fall, liegt nur eine gemeinsame Adresse für Lieferung und Rechnung vor.<\/p>\n Dann soll die Firma (so vorhanden) aus dem Feld company <\/b>der Tabelle s_user_billingaddress <\/b>im Feld Firma <\/b>landen (b.company<\/b>).<\/p>\n Ist s.salutation <\/b>nicht Null, enthält die Shopdatenbank zwei verschiedene Adressen für Rechnung und Lieferung. In diesem Fall soll die Firma aus dem Feld company <\/b>der Tabelle s_user_shippingaddress <\/b>in das Feld Firma <\/b>eingetragen (s.company<\/b>) werden.<\/p>\n Dies gilt dann auch für die übrigen Felder, die in den Kundendaten für die kombinierte Rechnungs-\/Lieferanschrift eingetragen werden sollen – also in Firma<\/b>, AnredeID<\/b>, Vorname<\/b>, Nachname<\/b>, Strasse<\/b>, PLZ<\/b>, Ort <\/b>und Land<\/b>.<\/p>\n Die benötigten berechneten Felder sind mal mehr, mal weniger kompliziert. Bei der Adresse zum Beispiel finden wir einen der Werte mr <\/b>(männliche Anrede) oder mrs <\/b>(weibliche Anrede) vor.<\/p>\n Diese wollen noch separat untersucht und in die Werte 1 <\/b>oder 2 <\/b>umgewandelt werden, bevor sie im Feld AnredeID <\/b>landen. Warum 1 <\/b>und 2<\/b> Weil das Feld AnredeID <\/b>mit der Tabelle tblAnreden <\/b>verknüpft ist, welches den Datensatz mit dem Primärschlüsselwert 1 <\/b>und der Anrede Herr <\/b>und den Datensatz mit dem Primärschlüsselwert 2 <\/b>und der Anrede Frau <\/b>enthält.<\/p>\n Der folgende Ausdruck wertet erst den Zahlenwert für mr <\/b>oder mrs <\/b>aus und weist dem Feld AnredeID <\/b>dann entweder den aus s.salutation <\/b>oder b.salutation <\/b>resultierenden Wert zu:<\/p>\n Bei den Feldern Vorname <\/b>und Nachname<\/b> sowie PLZ <\/b>und Ort <\/b>erfolgt die Ermittlung analog zum Feld Firma<\/b>:<\/p>\n Die Straße wird wieder interessanter, weil die Shopdatenbank diese in zwei Feldern speichert (street <\/b>und street-number<\/b>), die für die Kundendatenbank wieder zusammengeführt werden müssen – wiederum in Abhängigkeit vom Wert des Feldes b.salutation<\/b>:<\/p>\n Als letztes Feld des ersten Adressdatensatzes fehlt noch das Land. Das entsprechende Textfeld countryname<\/b> entnehmen wir in dem Fall, dass eine Lieferadresse vorliegt, aus dem Feld countryname <\/b>der ersten verknüpften Tabelle s_core_countries<\/b>, sonst aus der zweiten mit der Bezeichnung s_core_countries_1<\/b>:<\/p>\n Damit haben wir mit jedem der zuvor beschriebenen berechneten Feldern beide Fälle abgedeckt – sowohl den, dass nur eine Liefer-\/Rechnungsadresse vorliegt also auch separate Adressen für Lieferung und Rechnung. Ziel waren jeweils die Felder für die Liefer-\/Rechnungsadresse der Tabelle tblKunden<\/b>, die nur dann ausschließlich als Lieferadresse dienen, wenn es eine eigene Rechnungsadresse gibt.<\/p>\n Diese Rechnungsadresse wollen wir nun zusammenstellen. Fest steht: Wenn im Onlineshop keine separate Lieferadresse angegeben wurde, dann wird die dortige gemeinsame Liefer-\/Rechnungsadresse auch in der Kundendatenbank als Liefer-\/Rechnungsadresse genutzt.<\/p>\n Dies ist gleichbedeutend damit, dass die Rechnungsadresse in der Kundendatenbank leer bleibt. Diesem tragen die folgenden berechneten Felder der Abfrage qryUserBillingShipping_With_Countries <\/b>Rechnung.<\/p>\n Das Feld Firma_Rechnung <\/b>bleibt somit leer, wenn auch die Anrede der Lieferadresse des Kunden aus dem Shopsystem leer ist. Anderenfalls landet die für die Rechnungsadresse angegebene Firma im Feld Firma_Rechnung<\/b>:<\/p>\n Auf ähnliche Weise werden auch die übrigen berechneten Felder gefüllt:<\/p>\n Damit ist die Abfrage zum Zuweisen der Liefer- und Rechnungsadressen aus dem Shopsystem an die Felder der tblKunden <\/b>in der Kundendatenbank fertiggestellt.<\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n Dieser Beitrag hat gezeigt, wie Sie eine ungünstige Konstellation aus Quelltabellen und Zieltabellen über die Formulierung einer geeigneten Abfrage aneinander anpassen.<\/p>\n Die Abfrage liefert die Daten aus dem Shopsystem nun genau so aufgebaut, dass Sie diese direkt in die Kundentabelle importieren könnten.<\/p>\n Damit können Sie nun beispielsweise prüfen, ob sich die einmal übertragenen Daten zwischenzeitlich etwa in der Shopsoftware geändert haben, etwa weil der Benutzer dort seine Adresse geändert hat. Wie Sie einen solchen Abgleich durchführen, erfahren Sie im Beitrag Adressdaten abgleichen <\/b>(www.access-im-unternehmen.de\/979<\/b>).<\/p>\n Enthaltene Beispieldateien:<\/p>\n AdressenAusShop.mdb<\/p>\n![\"Herstellen](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_002.png\")
<\/p>\n![\"Für](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_003.png\")
<\/p>\n![\"Eingabe](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_004.png\")
<\/p>\n![\"Abfrage](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_005.png\")
<\/p>\n![\"Einstellen](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_006.png\")
<\/p>\n![\"Abfrage](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_007.png\")
<\/p>\n![\"Zieltabelle](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_008.png\")
<\/p>\n![\"Erweitern](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_009.png\")
<\/p>\n![\"Zusammenfassung](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_010.png\")
<\/p>\n![\"Abfrage-Datenquellen,](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_011.png\")
<\/p>\n![\"Benutzerdaten](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_012.png\")
<\/p>\n![\"Tabellennamen](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_013.png\")
<\/p>\n![\"Abfrage](\"..\/fileadmin\/_temp_\/2015_02\/pic_972_014.png\")
<\/p>\nFirma:Wenn(IstNull([s].[salutation]);[b].[company];[s].[company])<\/pre>\n
AnredeID: Wenn(IstNull([s].[salutation]);Wenn([b].[salutation]=\"mr\";1;2);Wenn([s].[salutation]=\"mr\";1;2))<\/pre>\n
Vorname: Wenn(IstNull([s].[salutation]);[b].[firstname];[s].[firstname])\r\nNachname: Wenn(IstNull([s].[salutation]);[b].[lastname];[s].[lastname])\r\nPLZ: Wenn(IstNull([s].[salutation]);[b].[zipcode];[s].[zipcode])\r\nOrt: Wenn(IstNull([s].[salutation]);[b].[city];[s].[city])<\/pre>\n
Strasse: Wenn(IstNull([s].[salutation]);[b].[street] & \" \" & [b].[streetnumber];[s].[street] & \" \" & [s].[streetnumber])<\/pre>\n
Land: Wenn(IstNull([s].[salutation]);[s_core_countries].[countryname];[s_core_countries_1].[countryname])<\/pre>\n
FFirma_Rechnung: Wenn(IstNull([s].[salutation]);Null;[b].[company])<\/pre>\n
Anrede_Rechnung: Wenn(IstNull([s].[salutation]);Null;Wenn([b].[salutation]=\"mr\";1;2))\r\nVorname_Rechnung: Wenn(IstNull([s].[salutation]);Null;[b].[firstname])\r\nNachname_Rechnung: Wenn(IstNull([s].[salutation]);Null;[b].[lastname])\r\nStrasse_Rechnung: Wenn(IstNull([s].[salutation]);Null;[b].[street] & \" \" & [b].[streetnumber])\r\nPLZ_Rechnung: Wenn(IstNull([s].[salutation]);Null;[b].[zipcode])\r\nOrt_Rechnung: Wenn(IstNull([s].[salutation]);Null;[b].[city])\r\nLand_Rechnung: Wenn(IstNull([s].[salutation]);Null;[s_core_countries].[countryname])<\/pre>\n
Downloads zu diesem Beitrag<\/h3>\n