Infrastructure Administrator 2013 - SP2.1 lässt sich nicht installieren

Ich hatte SP2 unmittelbar nach der Veröffentlichung heruntergeladen und installiert um zu schauen, ob ein von uns gemeldeter Fehler behoben wurde.

Die Installation lief damals durch. Dann wurde aber kurz darauf  SP2.1 veröffentlicht aufgrund eines Fehlers in SP2. Also habe ich SP2.1 heruntergeladen und installiert.

Heute wollten wir auf einem zweiten PC das SP2.1 installieren - aber nur SP2.1 für Map liess sich installieren. Beim Ausführen des SP2.1 für den Infrastructure Adminitrator erschien folgende Meldung:

"Dieses Servicepack konnte nicht installiert werden, weil es nicht für die auf Ihrem Computer installierte Version von Autodesk Infrastructure Administrator 2013 bestimmt ist."

Merkwürdig - bei meinem PC lief die Installation damals ohne Probleme durch. Beim Doppelklick auf das Update erscheint nun bei mir die Meldung : "Programm ist schon aktuell". In der Systemsteuerung ist auch ersichtlich, dass SP2.1 installiert ist:

Ich hatte mir gedacht, dass vielleicht ein neuer Download der Datei das Problem beheben könnte.  Zu meiner Überraschung musste ich feststellen, dass es inzwischen für den Administrator ein SP2.11 gibt. Nach dem Herunterladen der dritten Version des SP2 liess sich dieses nun auf den Rechnern installieren.

Map 2013, SP2 / SP2.1/ SP2.11

Formulare testen im Map - Administrator

Wenn man Formulare im Map-Administrator testet sollte Vorsicht walten. Solange man keinen Grafikaufbau durchgeführt hat, verhalten sich die Formulare im Administrator und in Map unterschiedlich

Im Beispiel darf der Benutzer nur eine Datumsangabe ändern. Alle anderen Formularelemente sind zur Bearbeitung gesperrt. Ein kurzer Test im Administrator funktioniert wie erwartet  - das Datum lässt sich ändern, die anderen Angaben nicht. Das gleiche Ergebnis erhält man, wenn das Formular in Map geöffnet wird aber noch kein Grafikaufbau durchgeführt wurde.

Nach dem Grafikaufbau in Map und der Änderung des Datums im Formular kam es im speziellen Fall bei mir zu der folgenden Fehlermeldung:

Ausnahme in FDO-Komponente

Objekt konnte nicht aktualisiert werden.

FDO-Befehl konnte nicht ausgeführt werden.

ORA-22804: Remote Vorgänge auf Objekttabellen oder benutzerdefinierte Typspalten nicht erlaubt.

Die vollständige Meldung:

:

:

Es scheint (schaut man auf die Fehlermeldung), dass Map nicht nur die Felder aktualisiert, deren Werte sich geändert haben, sondern alle Werte aus dem Formular im UPDATE zurückschreibt. Soweit ich verstehe, schlägt das UPDATE nun wegen der Geometrie-Spalte fehl.  Die fragliche Featureklasse ist über einen DB-Link in die Map-Fachschale eingebunden  - dies scheint eine Einschränkung von Oracle zu sein (https://forums.oracle.com/thread/377036).

Solange kein Bildaufbau erfolgt ist, wird scheinbar beim Update die Geometrie-Spalte ignoriert. Erst mit einem Bildaufbau wird die Geometrie in das UPDATE einbezogen – auch wenn sie sich nicht verändert hat.

Ein Test im Administrator oder in Map ohne Grafikaufbau kann also zu einem falschen Ergebnis führen.

SQL Abfragen mit WITH

Weil wir einige Performanceprobleme mit der Fachschale AW hatten habe ich u.a. mit SQL Spy mal beobachtet, welche Abfragen ablaufen. Dabei ist mir eine Abfrage aufgefallen, deren Syntax ich nicht kannte:

WITH CONNECTION AS ...

Zufällig habe ich einen passenden Blog-Beitrag zu diesem Thema gefunden:

http://sql-plsql-de.blogspot.ch/2013/09/plsql-code-in-einer-sql-abfrage-ja.html
http://sql-plsql-de.blogspot.co.uk/2008/12/subuqery-oder-inline-view-die-sql-with.html

Map-Benutzername DB-seitig (Oracle) ermitteln

Um den aktuellen Map-Benutzernamen oder -ID über einen Trigger zu loggen, z.B. um die Bearbeitung eines Datensatzes zuordnen zu können, lässt sich folgende SQL Abfrage verwenden:

user_name := job3.gettbuser();

bzw.:

SELECT USER_MGMT.GETVALUE('LOGIN_ID')into user_id FROM dual;
Der Aufruf von Job3 funktioniert unabhängig davon, ob das Dokument job-aktiv ist oder nicht.

Map 2013, SP2.

Abwasser - Globales Akutalisieren oder Blättern im Formular langsam?

Wir mussten feststellen, dass das Blättern vom einem Datensatz zum nächsten in der Haltungsmaske bis zu 5 sec dauert. Auch ein Globales Update bei den Schächten für rund 140 Datensätze dauerte mehr als 30 Minuten. Wir arbeiten bei der Fachschale nicht mit Jobs - bei Job-aktiven Dokumenten soll der Effekt noch schlimmer sein.

Schuld ist offenbar eine im CK WW (CH?) 2013 überarbeitete Funktion namens "GetPoint". Das Problem ist bei Autodesk inzwischen bekannt. Wir haben eine korrigierte Version der Funktion erhalten, die das Problem löst.

Ob dies auch mit der Ursache war für die schon vorher aufgefundenen Performanceprobleme in der AW Fachschale wird sich zeigen.

Map 2013, SP2.

Linienende immer zeichnen - Problem beim DWG-Export

Linienenden werden bei Map nicht zwangsläufig mit einer Strichsignantur beendet - im Gegensatz zu AutoCAD Linien. Ein - recht umständlicher - "Trick" um das von AutoCAD gewohnte Verhalten auch in Map nachzubilden ist im Geospatialnavigator-Blog beschrieben.

 

Leider gibt es dann beim DWG Export den unangenehmen Effekt, dass das als Linienende gedachte "Endstück"  zusätzlich als separate Linie vollständig exportiert wird.

 

Es ist nicht verständlich, warum die Map Darstellung nicht ohne weiteres vorsieht, dass ein Linienende immer mit einer sichtbaren Signatur enden kann. Das man umständlich einen solchen "Trick" anwenden muss, der dann weitere Nachteile nach sich zieht ist dann mehr als unbefriedigend.

DWG-Export mit Vorlage - Linientyp nicht in Vorlage gefunden.

Beim DWG-Export mit Vorlage kannn es zu folgender Meldung kommen:

 

Linientyp XYZ nicht in Vorlage gefunden. Stattdessen wird VonLayer verwendet.

 

obwohl der fragliche Linientyp in der DWT Vorlage enthalten ist.

 

Ursache ist, dass im Darstellungsmodell eine Referenz auf die importierte Liniendefinition enthalten ist. Dieser Verweis sieht in der Regel so aus:

 

<ExtendedData1>

<FileName>S:\GIS\MAPKonfig\Darstellungsmodelle\Vorlagen\Linienende.xml</FileName>

</ExtendedData1>

 

Importiert man einen Linienstil - wie im Beispiel aus einer XML Datei - wird der Pfad auf die importierte Datei mit in der Layerdefinition gespeichert. Dann kann aber das Problem beim Export entstehen - unabhängig davon, ob der Pfad zu der Datei noch gültig ist oder nicht.

 

Löscht man den Pfad bzw. den gesamten Eintrag aus der Layerdatei sollte der DWG Export ohne weiteres funtkionieren.