CRM MSSQL-Abfrage mit "." im Tabellennamen

[Manfred G]

Wie benutzen zur Verwaltung unserer Mieter eine Branchensoftware auf Basis einer MS SQL-Datenbank. Ich habe eine SQL-Abfrage formuliert und außerhalb von 3cx erfolgreich getestet.
Meine Abfragen werden beim Testen in 3cx aber immer wie folgt abgewiesen:

"Unknown expression: Person.Kommunikation. Part: Kommunikation."

Die Abfrage selbst sieht wie folgt aus:

Select
Namen.Personennummer As contactid,
Namen.Vorname As firstname,
Namen.Name1 As lastname,
Replace(Replace(Nummern.Daten, '+49 (', ''), ')', '') As phonehome

From
HAUSSOFT.vDatenuebergabe.[Person.Kommunikation] As Nummern Inner Join
HAUSSOFT.vDatenuebergabe.[Person.Name] As Namen On Namen.PersonUID = Nummern.PersonUID

Where
Replace(Replace(Nummern.Daten, '+49 (', ''), ')', '') Like Concat('%', @Number, '%')


Ich vermute, dass das Problem mit dem "." im Tabellennamen zusammenhängt. Kann das sein?
Gibt es eine andere Lösung?

Danke vorab,
Manfred

 

[mbehrens]

Wie benutzen zur Verwaltung unserer Mieter eine Branchensoftware auf Basis einer MS SQL-Datenbank. Ich habe eine SQL-Abfrage formuliert und außerhalb von 3cx erfolgreich getestet.
Meine Abfragen werden beim Testen in 3cx aber immer wie folgt abgewiesen:

"Unknown expression: Person.Kommunikation. Part: Kommunikation."

[...]

Ich vermute, dass das Problem mit dem "." im Tabellennamen zusammenhängt. Kann das sein?

Ja, siehe MS SQL Server Database Identifiers: Rules for regular identifiers

 

[Manfred G]

Dann war ich ja auf dem richtigen Weg. Vielen Dank.

Wenn ich die Datenbank nicht ändern kann, was bei uns der Fall ist, kann ich keine funktionierende Abfrage formulieren. Richtig?

 

[mbehrens]

Wenn ich die Datenbank nicht ändern kann, was bei uns der Fall ist, kann ich keine funktionierende Abfrage formulieren. Richtig?

Nein. Mögliche Lösungsansätze sind doch genau beschrieben. Funktionieren diese nicht?

 

[Manfred G]

Habe es gerade nochmal probiert: Eckige Klammern gehen nicht, aber die doppelten Anführungszeichen funktionieren. Die hatte ich nicht ausprobiert.
Vielen Dank für den erneuten Hinweis.

PS: Für alle Mitleser: Man muss die Variabel "@Number" vor dem Select noch deklarieren, z.B.:

DECLARE @Number VARCHAR(20)

 

[vieledinge]

HAUSSOFT.vDatenuebergabe.[Person.Kommunikation]

Mich würde erst mal interessieren was hier eigentlich zusammengestückelt wurde. Ist vDatenuebergabe ne View? Soll Person.Kommunikation ein Feldname sein? Dann hat sich da aber jemand nicht mit Ruhm bekleckert. Feldnamen mit Punkt sind von Hause aus ne blöde Idee, da der Punkt im SQL-Server der Trenner zwischen den Objektebenen ist.

Falls bei Person.Kommunikation die Tabelle Person heißt und das Feld Kommunikation, dann können die eckigen Klammern weg.

Generell würde ich bei so systemübergreifenden Geschichten dazu raten die Datenbereitstellung soweit wie möglich in eine eigene View zu kapseln. Dort kann man dann schon die ganze Datenaufbereitung incl. passender Feldnamen, etc. umsetzen. Und das Fremdsystem bekommt dann nur noch die View untergeschoben und hat damit auch nur Zugriff auf genau die Daten, die es braucht. Außerdem kann man dann auf die View auch separate Rechte vergeben, womit man auch Schadwirkungen durch falsche Schreibzugriffe einfach unterbinden kann.

 

[Manfred G]

HAUSSOFT.vDatenuebergabe.[Person.Kommunikation]

Mich würde erst mal interessieren was hier eigentlich zusammengestückelt wurde. Ist vDatenuebergabe ne View? Soll Person.Kommunikation ein Feldname sein? Dann hat sich da aber jemand nicht mit Ruhm bekleckert. Feldnamen mit Punkt sind von Hause aus ne blöde Idee, da der Punkt im SQL-Server der Trenner zwischen den Objektebenen ist.

Falls bei Person.Kommunikation die Tabelle Person heißt und das Feld Kommunikation, dann können die eckigen Klammern weg.

Generell würde ich bei so systemübergreifenden Geschichten dazu raten die Datenbereitstellung soweit wie möglich in eine eigene View zu kapseln. Dort kann man dann schon die ganze Datenaufbereitung incl. passender Feldnamen, etc. umsetzen. Und das Fremdsystem bekommt dann nur noch die View untergeschoben und hat damit auch nur Zugriff auf genau die Daten, die es braucht. Außerdem kann man dann auf die View auch separate Rechte vergeben, womit man auch Schadwirkungen durch falsche Schreibzugriffe einfach unterbinden kann.

Wie gesagt, bin ich nur Nutzer der Software und nicht der Ersteller, aber offensichtlich handelt es sich bei HAUSSOFT.vDatenuebergabe.[Person.Kommunikation] um einen View. Andere Tabellen haben kein kleines "v" im Namen. Da die Software schon 20 Jahre auf dem Markt ist, hat sich sicher auch einiges bzgl. der "best practice" getan. Und deren Entwicklungsumgebung kenne ich natürlich auch nicht. Die Tabelle heißt halt so.

Bzgl. der Rechteproblematik gebe ich Dir Recht. In 3cx muss ich die Zugriffsdaten zur Datenbank im Klartext eintragen, was mir nicht gefällt, da es im Browser auch nicht als Passwort verschlüsselt dargestellt wird. Da wir aber nur ein sehr kleines Unternehmen sind, 3cx auf dem eigenen Server läuft und ich Geschäftsführer und Admin bin, reduziert sich das Problem.

Ich könnte zwar einen eigenen View in der Datenbank erzeugen, möchte aber nicht in die Datenbank der Fremd-Software eingreifen, um eventuelle Probleme beim Service zu vermeiden. Wie man einen Benutzer anlegt, der dann nur den View sehen kann, entzieht sich zudem meinen Kenntnissen . Außerdem kommen regelmäßig Updates, bei denen ich nicht weiß, ob mein View anschließend weg ist. Da ist es einfacher, die Abfrage von außen vorzunehmen.