[PostNAS Suite] NAS Import nach SQL Server

[Gunter Becker]

Hallo Frank,

 > Wenn man die PG-Syntax in M$-Syntax umschreiben kann, mag das einfach gelingen. 

So hätte ich es wahrscheinlich versuchen! Allerdings stellt sich mirdann mittlerweile doch die Frage, ob ich das alles in einem vernünftigen Zeitrahmen hinbekommen kann. Ich vermute fast nicht! Da ich momentan die SQLite-Datei standalone benutze, also ohne jegliche Verknüpfung mit anderen Daten, könnte ich genauso gut auch PostgreSQL/PostGIS benutzen, um die Daten zu visualisieren und anderweitig abzufragen. Wie bereits erwähnt, wäre das nur wegen der "Zumutbarkeit" einer zweiten DB auf dem Server ein Hinderungsgrund gewesen. Da muss ich halt ein bisschen Überzeugungsarbeit leisten, dann wird das schon!

Gruß und vielen Dank für die ausführliche Erklärung.

Gunter


 
Erst als ich genügend Informationen von Seiten der PostNAS-Entwickler *und* auch von Seiten der ALKIS-Hersteller miteinander kombiniert habe, ist es gelungen, die letzten Fehler aus dem Trigger zu bekommen. Bis dahin bin ich immer von falschen Voraussetzungen ausgegeben.

PostNAS:
 Erst werden alle INSERT in der NAS-Datei abgearbeitet, dann wird die Datei ein zweites Mal durchlaufen und die DELETE usw. werden in die delete-Tabelle eingetragen.

ibR:
 Um einen Sekundärbestand mit Vollhistorie per NBA aufzubauen, legt man den Stichtag weit in die Vergangenheit und gibt zunächst einen Grundbestand aus, der leer ist.
 Der erste Aktualisierungslauf bringt dann alle Änderungen (alle Zwischenstände!) mit, die seit dem Beginn aller ALKIS-Zeiten erfolgt sind.

Daraus folgt für ein Objekt, dass bisher schon mehrfach geändert wurde:
  Alle historischen Versionen eines Objektes kommen in einer NAS-Datei.
  Der erste PostNAS-Durchlauf trägt das Objekt mehrfach als aktuell ein.
  Der zweite PostNAS-Durchlauf trägt mehrere Änderungssätze für das Objekt in die Delete-Tabelle ein.
  Jeder Eintrag in die delete-Tabelle löst den Trigger einmal aus.

Wenn der Trigger ausgelöst wird, findet er also folgendes vor:
  Er soll eine Vorgängerversion eines Objektes terminieren (endet=), es gibt aber mehrere noch nicht terminierte Objekt-Versionen in der Datenbank.
  Er darf nicht einfach alle terminieren, sondern er muss die richtige Version finden, den unmittelbaren Vorgänger.
  Spätere Aufrufe des Triggers finden bereits terminierte Versionen des Objektes und auch einen Restbestand an aktuellen Versionen.

Am Ende sollte genau eine aktuelle Version übrig bleiben, oder im Falle von DELETE als letzte Operation auch keins.


MfG
F. Jäger


Von: NAS [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Gunter Becker
Gesendet: Mittwoch, 7. September 2016 16:43
An: PostNAS Suite - ALKIS, ATKIS, ABK - NAS Schnittstelle via ogr2ogr
Betreff: Re: [PostNAS Suite] NAS Import nach SQL Server


Trigger und Prozeduren sollten kein Problem darstellen.   ..

Viele Grüße, Gunter