Vor Kurzem trat bei mir ein seltsamer Fehler auf. Folgendes Szenario lag vor:
- Eine Smartforms-Anwendung mit verschiedenen Smartobjekten sollte deployed werden
- Die Anwendung wurde auf dem Entwicklungsserver erstellt
- Als Datenbank diente eine MS SQL-Server Datenbank
- Alle Tabellen, Views und Stored Procedures der Anwendung wurden in einem eigenen Schema mit der Bezeichnung RKA angelegt
- Die Anwendung wurde nach Fertigstellung auf das Testsystem deployed (mit einer eigenen Datenbank für die Anwendungsdaten)
Nachdem ich die Tabellen auf dem Testsystem angelegt hatte, das Deploymentpaket auf dem Testsystem ausgebracht hatte sah erst mal alles gut aus.
Als ich dann die erste Smartform aufrufen wollte, die Datensätze anzeigen sollte, erhielt ich folgenden Fehler:
„No return properties. SmartObject: [NAME_DES_SMARTOBJEKTES] Method: [List]“
Das Problem konnte zwar auf dem Testsystem händisch gelöst werden, in dem man das Smartobjekt im Editiermodus im Designer öffnete und die „Service Object method bindings“ aufrief und mit OK bestätigte und das Smartobjekt speicherte, das kann es aber natürlich nicht sein, insbesondere wenn man viele Smartobjekte hat.
Also machte ich mich auf die Suche und wurde fündig bei einem kleinen aber feinen Unterschied: Das Schema auf dem Entwicklungssystem wurde mit Großbuchstaben (RKA) angelegt, auf dem Testsystem aber mit Kleinbuchstaben (rka)
Nach entsprechender Anpassung traten keine Fehler mehr auf – eine kleine Unachtsamkeit die mich leider einige Nerven und Zeit gekostet hat.
Im Übrigen wurde in einem anderen Fall eine andere Fehlermeldung angezeigt, die nach der Anpassung der Schemas aber auch gelöst wurde (ich vermute aber das hing auch mit der Migration von Version 4.7 auf 5.2 zusammen, die kurz zuvor durchgeführt wurde)
Die Fehlermeldung lautete: „An item with the same key has already been added“
Da sich ja nun ein Schema nicht einfach umbenennen lässt bin ich folgenden Weg gegangen (ich bin kein SQL-Guru, bestimmt würde es bessere bzw. einfachere Wege geben ;-)):
- Anlegen eines temporären Schemas: TEMP
- Ermitteln der Objekte, die dem fehlerhaften Schema zugeordnet sind – z.B.
SELECT *
FROM sys.objects
WHERE
schema_id=24 AND
type IN ('V','P','U')
V = View / P = Stored Procedure / U = Table (UserTable)
- Die Objekte dem temporären Schema zuordnen
ALTER SCHEMA TEMP TRANSFER rka.IhrTabellenName;
- Ich habe mir das etwas vereinfacht indem ich mir für die Objekte mit folgenden Statement die Befehle für alle Objekte generieren ließ (in meinem Fall hat das Schema rka die ID 24 – schema_id=24)
SELECT
'ALTER SCHEMA TEMP TRANSFER rka.' + name + ';'
FROM sys.objects
WHERE
schema_id=24 AND
type IN ('U')
- Altes Schema (rka) löschen
- Altes Schema mit richtiger Schreibweise anlegen (RKA)
- Den im Schema TEMP „geparkten“ Objekte dem neuen, richtig geschriebenen, Schema wieder zuweisen. Dazu können die erzeugten SQL-Statements erneut verwendet werden, jedoch muss eben die Schema-ID entsprechend angepasst werden und die Schemas im ALTER-Statement entsprechend angepasst werden.
SELECT
'ALTER SCHEMA RKA TRANSFER TEMP.' + name + ';'
FROM sys.objects
WHERE
schema_id=25 AND
type IN ('U')
ALTER SCHEMA RKA TRANSFER TEMP.IhrTabellenName;
schema_id=25 – 25 ist in meinem Fall die ID des temporären Schemas TEMP
Ich habe das in der Reihenfolge Tabellen, Views und Stored Procedures durchgeführt.
Natürlich könnten die Tabellen und das Schema auch einfach gelöscht werden und neue generiert werden, was aber lästig ist, wenn sich bereits Daten in den Tabellen befinden.
Bild von ❤️A life without animals is not worth living❤️ auf Pixabay