<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.E-MailFormatvorlage19
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.E-MailFormatvorlage20
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.E-MailFormatvorlage21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Hallo,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">> Hier wäre die logische Erklärung, das die NAS UTF8-codiert ist und der SQL-Server „anders“. Damit würde jeder Umlaut 2 Zeichen „einnehmen“.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Das war auch damals meine Erklärung für das Umlautproblem. Aber das ist ja durch den Bugfix im MSSQLSpatial-Treiber behoben worden
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Irgendwie hat mich die Sache mit dem vermeintlichen Codierungsproblem beim Suchen des Fehlers nun doch zu einem Treffer geführt, obwohl es mit der Codierung aber eigentlich nichts zu tun hat. Der MSSQLSpatial-Treiber importiert standardmäßig
 die Daten via „Bulk Copy“. Auf einer Seite von MS hab‘ ich dann diesen Satz gelesen, der ziemlich genau das beschreibt was ich als Ergebnis sehe:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="text-indent:35.4pt"><span lang="EN">At the beginning of each
<strong><span style="font-family:"Calibri",sans-serif">char</span></strong> or <strong>
<span style="font-family:"Calibri",sans-serif">varchar</span></strong> field, <strong>
<span style="font-family:"Calibri",sans-serif">bcp</span></strong> adds the prefix length.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN">Wenn ich nun den Parameter MSSQLSPATIAL_USE_BCP auf FALSE setze, so dass jeder Datensatz einzel geschreiben wird, dann werden die Daten korrekt nach SQL Server geschrieben. Allerdings nur bedingt! Leider musste ich dazu
 noch die Option -skipfailures im ogr2ogr Befehl mit angeben, da zahlreiche Insert-Befehle  zu einem neuen Fehler geführt haben und gar nicht erst importiert wurden: Memory allocation failure.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN">Naja, dann suche ich halt an der Stelle noch einmal nach einer Lösung. Wenigstens weiß ich jetzt wo die vorangestellten Zeichen herkommen.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN"><o:p> </o:p></span></p>
<p class="MsoNormal">> Was ist letztendlich das Ziel der Konvertierung? Shape-Files, Geodatenbank oder …?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Ja, Ziel ist eine Geodatenbank zum Anzeigen der Daten im WebGIS, Erstellen von Flurstücksauskünften, Suchen nach Adressen und Flurstücken und Verknüpfen der Daten mit anderen Themen der Anwendung. Das direkte Verknüpfen der ALKIS-Daten
  mit den anderen Themen unserer Anwendung würde ich hier als wichtigstes Argument anführen wollen. Für die Darstellung in der Kartenanwendung mag der SQL Server vermutlich nicht die beste Performance besitzen, bei Verwendung einer Vorab-Kachelung, wird es
 aber wahrscheinlich ausreichend sein. <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Viele Grüße,<o:p></o:p></p>
<p class="MsoNormal">Gunter<o:p></o:p></p>
</div>
</body>
</html>