MSSQL Feldname mit Umlaut :-(

[haentschman]

Hallo...:P

Gleich zum Anfang: Ich habe mir das nicht ausgedacht. :?

Ich habe in der DB noch Feldnamen in Tabellen die Umlaute besitzen. In der Regel macht das auch nix...mit [] eingeschlossen.
In letzter Zeit kommt beim "Refresh" des Datasets folgender Fehler:

Zitat:

[FireDAC][Phys][ODBC][Microsoft][SQL Server Native Client 11.0][SQL Server]Ungültiger Spaltenname "STÖTermin".

Das witzige ist, daß die Datenmenge schon vorher geladen war. :?

Code:

...
  B.[ixSTÖLoesung],
  B.[STÖNachTerminText],
  B.[STÖTermin],
  B.ixBELStatus
from
  TERMin T
  left outer join BELKopf B on (T.idBelKopf = B.idBelKopf)
  left outer join Employees A on (T.ixUserAn = A.EmployeeNameShort)
where
...

Wem muß beibringen, daß die Umlaute funktionieren sollen? :roll: DB oder FireDAC?

Danke...

[mikhal]

Aber das Feld [STÖNachTerminText] erkennt er?

In Oracle würde ich es hier mit Anführungsstrichen versuchen.

Grüße
Mikhal

[haentschman]

Danke...

Zitat:

In Oracle würde ich es hier mit Anführungsstrichen versuchen.

...beim Refresh? Query.Refresh? :zwinker:

[mikhal]

Nicht speziell beim Refresh sondern grundsätzlich.

Warum machst du an dieser Stelle ein Refresh? Hast du Daten geändert oder wurde der Datensatz von jemand anderem im Hintergrund geändert?

Wenn du selbst keine Änderungen vorgenommen hast, versuch es mal mit Close und Open. Tritt der Fehler dann immer noch auf? Dann liegt die Vermutung nahe, dass FireDAC der Übeltäter ist.

[haentschman]

Zitat:

von jemand anderem im Hintergrund geändert

...ja. :wink:

Ich bin gerade auf einer anderen Spur...Moment.

[mjustin]

Zitat:

Zitat von haentschman (Beitrag 1497772)

Hallo...:P

Ms Sql unterstützt auch den Sql Standard, nach dem Spaltennamen mit doppelten Hochkomma umgeben werden können.

[ ] sind DB spezifisch und daher nicht unbedingt in allen Client Bibliotheken in gleicher Qualität unterstützt.

[Sinspin]

Ich würde um jeden Preis versuchen die Umlaute loszuwerden.
Selbst wenn dafür die ganze DB neu erstellt werden muss und tausend Zeilen Quelltext zu ändern sind.
Die arbeit hat man nur einmal, den Ärger dafür andauernd.

[jobo]

Vielleicht wird ein Mix aus Persistenz Angaben und SQL verwendet?
Ehrlich gesagt, by MSSQL würde ich sowas auch in eckige Klammern setzen, allerdings eben im SQL Text, weniger bei Feldnamenangaben in irgendwelchen Objekteigenschaften. Vielleicht wird auch SQL Text gebaut? Oder Parameter bestückt, also nicht beim Ursprungsselect problematisch, sondern bei "späterer" Formularbedienung / Filterung?
Dann reicht irgendein seltenes Event vielleicht für den Fehler.
Schon mal im Code und im Formular nach dem Übeltäter gesucht? Debugged?

[Jasocul]

Zitat:

Zitat von Sinspin (Beitrag 1497781)

Ich würde um jeden Preis versuchen die Umlaute loszuwerden.
Selbst wenn dafür die ganze DB neu erstellt werden muss und tausend Zeilen Quelltext zu ändern sind.
Die arbeit hat man nur einmal, den Ärger dafür andauernd.

Erstelle eine View, die die Tabelle 1:1 abbildet. Die Feldnamen benennst du dort um. So kann man sukzessive die Anwendung(en) umstellen, ohne dass es Probleme gibt. Auch alle DML funktionieren dann. Wir haben sogar Bulk-Inserts die die View verwenden und fehlerfrei funktionieren.
Ob man dann später, wenn alles mit der View arbeitet, die Tabelle anpasst und diese wieder verwendet, kann man dann ja auch noch in Angriff nehmen. Allerdings habe ich gute Erfahrungen damit gemacht, in Anwendungen nur noch Views anzusprechen. Wenn dann Ergänzungen, Korrekturen oder ähnliches erforderlich sind, muss nur die View angepasst werden und nicht die Anwendung. Und solange es nur um Abfragen geht, kann man dafür UDF verwenden, die als Result eine "Tabelle" haben.

[TigerLilly]

Das kommt NUR bei B.[ixSTÖLoesung] oder bei allen mit Umlauten?

Verwende mal einen Alias. B.[ixSTÖLoesung] as B_ixSTOELoesung.
Schau auch mal mit dem Profiler/einem Trace, was auf der DB tatsächlich passiert. Der MSSQL Server allein ist hier sicher nicht das Problem.