[Gelöst] Tabellen vom SQL-Server füllen lassen

[Datenkultur]

Hallo liebe Mitentwickler,

ich habe eine Schnittstelle die per Servicebrooker eine Tabelle im SQL-Server füllt. Aus technischen Gründen werden die Daten per SP in eine Tabelle übertragen, die ich im NAV (2009 SP1) verwende. Leere Felder initialisiere ich in dem SP mit Standardwerten. Im NAV kann ich mit allen Feldern arbeiten und meine Anwendung schnurrt friedlich vor sich hin. So weit so gut.

Ich habe nun eine NAV-Sicherung ausführen wollen. Die schlägt mir aber leider bei der genannten Tabelle fehl. NAV ist der Meinung, das die Tabelle fehlerhaft ist. (Die genau Fehlermeldung habe ich gerade nicht vorliegen). NAV weist aber daraufhin, das es evtl. an externen Programmen liegen könnte.

Was ist der Grund für den Fehler? Was kann ich gegen den Fehler unternehmen?

Zuletzt geändert von Datenkultur am 6. September 2011 18:49, insgesamt 1-mal geändert.

Mach doch mal einen FINDSET/REPEAT UNTIL auf die Tabelle. Dann solltest du einen Fehler bekommen, sobald ein Datensatz angesteuert wird, welcher einen für Navision fehlerhaften Datensatz enthält (Beispiel Kleinbuchstaben im Codefeld).

Hallo Sebastian,

danke für die Idee. In der Tabelle sind nur ein paar Testdaten und das Lesen aller Daten passiert ständig. Die Sätze können alle gelesen und beschrieben werden.

Die genau Fehlermeldung habe ich gerade nicht vorliegen

Wenn die Fehlermeldung wieder kommt, kopiere sie bitte mittels Strg+C und füge sie hier wieder ein; dann kann man danach suchen. Danke!

Hallo Natalie,

ich habe es eben noch einmal durchlaufen lassen. Bitte nicht erschrecken:

Vorsicht: In der Datenbankstruktur liegt ein Fehler vor. Ein solcher Fehler tritt auf, wenn die Datenbankdatei von einem anderen Programm verändert wird oder eine Fehlerfunktion eines Gerätetreibers vorliegt.

Sie müssen diesen Fehler beheben, bevor Sie mit dem Programm weiterarbeiten. Der Fehler (1190 im Modul '19') wurde eventuell vom Computer oder von einem Programm verursacht.

Tabelle: EOS SchnittstellenkopfMandant: Schlüsselfelder: Lfd. Nr.Führen Sie zunächst einen Datenbanktest durch. Klicken Sie dazu im Menü 'Datei' auf 'Datenbank', klicken Sie auf 'Prüfen', und wählen Sie 'Maximum' aus. Gehen Sie folgendermaßen vor, wenn derselbe Fehler erneut auftritt:

1. Erstellen Sie eine Sicherheitskopie der Datenbank, indem Sie die Datenbankdatei(en) an einen anderen Speicherort kopieren.

2. Erstellen Sie mit der integrierten Funktion eine Sicherheitskopie.

3. Sollte dies erfolgreich verlaufen, erstellen Sie eine neue Datenbank, ohne die fehlerhafte Datenbank zu löschen.Stellen Sie die mit der integrierten Datensicherungsfunktion erstellte Sicherungskopie in der neuen Datenbank wieder her, und testen Sie sie. Klicken Sie dazu im Menü 'Datei' auf 'Datenbank', klicken Sie auf 'Prüfen', und wählen Sie dann 'Maximum' aus.

Lässt sich das Problem auf diese Weise nicht beheben, gehen die nach der letzten Sicherung vorgenommenen Änderungen verloren. Lesen Sie Ihre letzte Datensicherung ein, und prüfen Sie die Datenbank mit den bereits erwähnten Methoden.Aus Sicherheitsgründen sollten Sie die alte Datenbank erst löschen, nachdem Sie die neue Datenbank eine Weile verwendet haben.

Wenden Sie sich an den Systemadministrator, wenn Sie Hilfe benötigen.

Tja... der Systemadministrator bin ich

Damit gehts direkt einen Schritt weiter bei der Ursachenforschung:
Interner Fehler 1190 in Modul 19

Hier liegt wahrscheinlich ein Datenfehler vor. D.h. ein Codefeld mit falschen Werten (z.B. 'ß', kleinbuchstaben,...), NULL-Werte o.ä.. Da hilft leider nur Kontrolle der Daten.

Gruß, Fiddi

@Natalie: Danke für den Link. Das klärt einiges
@Fiddie: Danke für den Tip. Da kann ich nachher lossuchen.

Des Rätsels Lösung:

Ich hatte versehentlich ein Feld, dass von aussen gefüllt wurde, als Codefeld erstellt. Der Tester hat im Fremdsystem mit kleingeschriebenem gearbeitet.

Das Feld habe ich erst mal in Text umgewandelt. Als weiteres Problem hat sich ergeben, dass Textfelder einfach in Codefelder per C/AL Code übergeben werden können. Es wird nicht konvertiert. Leerzeichen vorher oder nachher und kleingeschriebenes mag Navision in Codefeldern aber gar nicht.

Mit dem folgenden Statement kann man beliebige Textfelder in Codefelder wandeln:

Code:

"Code Field" := UPPERCASE(DELCHR("Text Field",'<>',''));

Herzlichen Dank für die Hilfe.

Ich hatte versehentlich ein Feld, dass von aussen gefüllt wurde, als Codefeld erstellt. Der Tester hat im Fremdsystem mit kleingeschriebenem gearbeitet.

Meine StoredProcedures sind niet- und nagelfest. Heißt, dass ich solche Dinge einfach verhindere. Zum Beispiel Codefelder erhalten automatisch ein UPPER() bevor der INSERT oder UPDATE passiert. Und bei jeden Feld prüfe ich, ob nicht doch ein NULL-Wert sich reinschleichen kann. Das ist zwar alles aufwendig, aber nur so kann man die Integrität der Datenbank sicherstellen. Externe Systeme dürfen also nur über StoredProcedures Daten pumpen.

Hallo Sebastian,

das finde ich sinnvoll wie Du es beschreibst. Bei Codefeldern ist das ja sogar zwingend erforderlich, wie ich feststellen durfte. Aber auch bei Texten lohnt es sich. So hatte bei mir das liefernde System Textfelder zwar anstandslos gefüllt, ich konnte im NAV aber nur begrenzt darauf filtern weil folgende Leerzeichen enthalten waren, die man ja mit bloßem Auge erst mal nicht sieht.

Fazit:

- NAV-unabhängige Stagingarea für die Rohdaten erstellen
- Die importierten Daten z.B. per Insert-Trigger in die NAV-Tabelle übertragen
- Alles im SP abfangen, was man abfangen kann:

- Standard-Leerwerte statt NULL
- Upper() bei Codefeldern
- LTrim() + RTrim() bei Codefeldern und Texten, die keine führenden oder folgenden Leereichen haben dürfen/sollen
- Left() zum Begrenzen von Text-Feldlängen

Anmerkung:
- Die NAV Tabelle sollte auf jeden Fall durch NAV erstellt werden.
- Wenn man Felder im NAV hinzufügt, dann muss man zu allermeist auch den SP anpassen, denn neue Sätze brauchen wieder Default-Werte für das neue Feld und das kann ja zum Erstellzeitpunkt noch gar nicht in dem SP vorhanden sein.