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.

[haentschman]

Hallöle...

Zitat:

B.[STÖTermin],

...sowohl im SQL als auch in der Felddefinion der Query entfernt. -> Refresh funktioniert. :shock:

Ich hatte die Vermutung weil in der Felddefinion kein "Orgin" eingetragen war [STÖTermin]
... das wars aber auch nicht. :cry:

Zitat:

Ich würde um jeden Preis versuchen die Umlaute loszuwerden.

Ganz ehrlich? Dafür ist keine Zeit vorhanden. :?

Zitat:

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

...nur bei [STÖTermin]

[Jasocul]

Die einzige Besonderheit beim Refresh, die mir im Moment einfällt, ist die Eigenschaft "Prepared". Vielleicht gibt es damit Probleme, wenn die Parametrisierung dein Feld (nicht) berücksichtigt?
Um das zu prüfen könntest du ein close, unprepare und open machen. Wenn das funktioniert, könnte da die Ursache sein.
Aber ganz ehrlich: Ich stochere da jetzt nur im Nebel und das kann daher auch völliger Unsinn sein.

[haentschman]

Zitat:

Ich stochere da jetzt nur im Nebel und das kann daher auch völliger Unsinn sein.

Willkommen im Club...:wink:

Ich habe die Felddefinition aus der "Original" Query in diese Qery kopiert, B.[STÖTermin] in SQL wieder ergänzt, ... Fehler! "Ungültiger Spaltenname..."

PS: Vor dem Refresh ins DataSet geschaut. Das Feld "STÖTermin" ist vorhanden und gefüllt.

:gruebel:

[Jasocul]

Kannst du mal ein DDL der Tabelle erstellen und ins Forum setzen? Vielleicht gibt es irgendeine Besonderheit.

[haentschman]

Bitteschön...(gekürzt):wink:

Code:

CREATE TABLE [dbo].[Tablexxx](
...
   [SPStöSachbearbeiter] [nvarchar](50) NULL,
   [SPStöZugestelltAm] [datetime] NULL,
   [STÖErledigtAm] [datetime] NULL,
   [STÖErledigtVon] [nvarchar](6) NULL,
   [STÖErfasstAm] [datetime] NULL,
   [STÖErfasstVon] [nvarchar](6) NULL,
   [STÖReaktionBis] [datetime] NULL,
   [STÖBearbeitetAm] [datetime] NULL,
   [STÖBearbeitetVon] [nvarchar](6) NULL,
   [STÖDauer] [datetime] NULL,
   [STÖZeit] [int] NULL,
   [STÖAuftragsNr] [nvarchar](30) NULL,
   [STÖMonteur] [nvarchar](6) NULL,
   [STÖMonPlan] [datetime] NULL,
   [STÖMontEintrAm] [datetime] NULL,
   [STÖMontEintrVon] [nvarchar](6) NULL,
   [STÖWann] [datetime] NULL,
->   [STÖTermin] [datetime] NULL,
   [STÖMoSchein] [nvarchar](1) NULL,
   [STÖweiterAnfahrt] [nvarchar](1) NULL,
   [STÖFremd] [nvarchar](1) NULL,
   [STÖFremdAm] [datetime] NULL,
   [STÖFremdVon] [nvarchar](6) NULL,
   [STÖAnNetto] [nvarchar](1) NULL,
   [ixSTÖArt] [nvarchar](50) NULL,
   [STÖStoerung] [nvarchar](max) NULL,
   [STÖBemerkung] [nvarchar](max) NULL,
   [ixSTÖLoesung] [nvarchar](50) NULL,
   [STÖNochmal] [nvarchar](1) NULL,
   [STÖNachTermin] [datetime] NULL,
   [STÖNachTerminText] [nvarchar](max) NULL,
   [STÖIntervall] [int] NULL,
   [STÖWer] [nvarchar](50) NULL,
   [STÖTelefon] [nvarchar](50) NULL,
   [STÖAbgeschlossen] [nvarchar](1) NULL,
   [STÖWarenschaden] [nvarchar](1) NULL,
   [STÖTempAnkunft] [numeric](7, 1) NULL,
   [STÖTempAbfahrt] [numeric](7, 1) NULL,
...

In der Query sind die datetime Felder als TSQLTimeStampField deklariert.

[Jasocul]

Ich sehe nix Besonderes. Aber ein Versuch war es Wert.
Ich würde jetzt noch Versuchen, eine Mini-Anwendung zu erstellen, die die Daten abruft und dann ein Refresh macht. Das Ganze ohne C&P, um wirklich einen Standard-Zustand in den Komponenten zu haben.
Falls damit alles funktioniert, liegt es an der Anwendung, wenn nicht, bin ich dann auch erstmal überfragt.

[haentschman]

Hallöle...:P

Danke für euren Beistand. :love:

Durch die Diskussion bin ich auf die Lösung gekommen... :thumb:

Ich habe mir mal das SQL (CommandText) im "Refresh" anzeigen lassen. Das SQL war nicht das was ich erwartet hatte. :shock: Der wollte ein Update machen mit "STÖTermin". :shock:
Im Update gehört das Feld "STÖTermin" nicht hin weil nicht vorhanden! Das SQL ist ein Join...

Das Feld überprüft...:oops: Schei...gebaut. Der Haken für pfInUpdate war gesetzt.

...ich brauche Urlaub. :wink: