Fortsetzung OPENROWSET

[Sabine Bergmann]

Hallo,
mit Trick vielen Bemühunges ist es gelungen, in der OPENROWSET-FUNKTION doch eine WHERE Klausel mit einer Variablen unterzubringen. Das hat einen durchschlagenden Effekt auf die Geschwindigkeit (ca 1:400). Bei der Ausführung kommt aber folgende Fehlermeldung
"Heterogene Abfragen erfordern, dass die Optionen ANSI_NULLS und ANSI_WARNINGS für die VERBINDUNG eingestellt werden. So wird eine konsistente Abfragesemantik sichergestellt. Bitte aktivieren Sie diese Optionen und wiederholen Sie dann die Abfrage."
Ich habe in der aufrufenden Datenbank und in der Remotedatenbank die Optionen entsprechend eingestellt. Hier wird aber die VERBINDUNG angesprochen. Wo muß ich die Optionseinstellung unterbringen? innerhalb der Funktion, die ja auch den Connnectionstring enthält?? Aber wie?)
Danke für schnelle und fachkundige Antwort!

[Andreas Kosch]

Hallo,

der OPENROWSET-Weg ist nur die 2. Wahl, besser ist es, einen echten <i>linked Server</i> einzurichten, wenn die Anwendung häufiger auf den Ziel-Server zugreifen soll. Im Fall des linked Servers können die Optionen gezielt gesetzt werden, wie das folgende Beispiel zeigt:
<pre>
<font color="#008080">-- Schritt 1: Systemprozedur richtet einen linked Server unter dem
-- virtuellen SQL Server-Namen »ZielServer« ein.
-- Parameter:
-- a) @server : Der vom Script genutzte Name
-- b) @srvproduct : Beim Zielserver MS SQL Server bleibt der Eintrag leer!
-- c) @provider : Name des OLE DB-Providers für den MS SQL Server
-- d) @datasrc : Rechnername des Ziel-MS SQL Servers (bzw. benannter Instanzname)</font>
<br>
<b>EXEC</b> sp_addlinkedserver
@server=<font color="#9933CC">'ZielServer'</font>,
@srvproduct = <font color="#9933CC">''</font>,
@provider = <font color="#9933CC">'SQLOLEDB'</font>,
@datasrc = <font color="#9933CC">'P4W2K'</font>
<b>GO</b>
<br>
<font color="#008080">-- Schritt 2: Login-Information für die SQL Server-Anmeldung beim Linked Server einrichten
-- Parameter:
-- a) @rmtsrvname = Der von sp_addlinkedserver zugewiesene virtuelle SQL Server-Name
-- b) @useself = Keine Windows-Authentifizierung verwenden
-- c) @rmtuser = Benutzername des gelinkten MS SQL Servers (Ziel-Server)
-- d) @rmtpassword = Passwort des Benutzernamens »@rmtuser«</font>
<br>
<b>EXEC</b> sp_addlinkedsrvlogin
@rmtsrvname=<font color="#9933CC">'ZielServer'</font>,
@useself=<font color="#9933CC">'false'</font>,
@rmtuser=<font color="#9933CC">'sa'</font>,
@rmtpassword=<font color="#9933CC">'geheimesPasswort'</font>
<b>GO</b>
<br>
<font color="#008080">-- Schritt 3: Server-Optionen konfigurieren (Beispiel RPC OUT)
-- Parameter:
-- a) Der von sp_addlinkedserver zugewiesene virtuelle SQL Server-Name
-- b) Option »rpc out« selektiert das Ausführungs-Recht für Prozeduren
-- c) Wert »on« aktiviert die unter b) definierte Option</font>
<br>
<b>EXEC</b> sp_serveroption <font color="#9933CC">'ZielServer'</font>,<font color="#9933CC">'rpc out'</font>,<font color="#9933CC">'on'</font>
<b>GO</b>
<br>
<font color="#008080">-- Schritt 4: Zur Kontrolle die Situation prüfen</font>
<br>
<b>EXEC</b> sp_helpserver
<b>GO</b>
</pre>
Der Weg über den linked Server hat auch den Vorteil, dass die Ausgangsdatenbank die SQLs direkt auf den virtuellen Servernamen abschicken kann, d.h. es gibt dann keinen Unterschied mehr zu Zugriffen auf lokale Datenbanken

[Sabine Bergmann]

Wiederum Danke für die schnelle Antwort!
Das Problem. Ich will eine Datenbank mit ca 8 Mill. Datensätzen abfragen. Das von Ihnen empfohlenen Verfahren (allerdings manuell per Enterprise Manager) hatte ich vorher angewandt.
Die Abfragen lieferten öfter time out -Meldungen. Mit der Openrowset(bzw. Openquery)-Funktion konnte ich nun das Problem beheben, aber nur, wenn die Where-Klausel INNERHALB der Funktion steht). Um das zu erreichen, habe ich den gesamten SQL-String dynamisch zusammengesetzt und in eine Variable @strSQL gelegt und dann mit 'execute @strSQL 'ausgeführt. Das ging im Query-Analyser und führte zu passablen Abfragezeiten. Bei Übernahme in eine gespeicherte Funktion kam aber die ANSI_Fehlermeldung, evtl. aufgrund unterschiedlicher Server-Versionen (??).
Inzwischen ist es mir gelungen, mit der Funktion OPENDATASOURCE den gewünschten Effekt zu erreichen. Ich habe zu diesem Zweck auf dem Remoteserver eine gesp. Prozedur abgelegt, die ich mit der Funktion aufrufe

[hmx]

linked server für dBase IV (und 5)

Hallo,

der OPENROWSET-Weg ist nur die 2. Wahl, besser ist es, einen echten <i>linked Server</i> einzurichten, wenn die Anwendung häufiger auf den Ziel-Server zugreifen soll. Im Fall des linked Servers können die Optionen gezielt gesetzt werden, wie das folgende Beispiel zeigt:
<pre>
<font color="#008080">-- Schritt 1: Systemprozedur richtet einen linked Server unter dem
-- virtuellen SQL Server-Namen »ZielServer« ein.
-- Parameter:
-- a) @server : Der vom Script genutzte Name
-- b) @srvproduct : Beim Zielserver MS SQL Server bleibt der Eintrag leer!
-- c) @provider : Name des OLE DB-Providers für den MS SQL Server
-- d) @datasrc : Rechnername des Ziel-MS SQL Servers (bzw. benannter Instanzname)</font>
<br>
<b>EXEC</b> sp_addlinkedserver
@server=<font color="#9933CC">'ZielServer'</font>,
@srvproduct = <font color="#9933CC">''</font>,
@provider = <font color="#9933CC">'SQLOLEDB'</font>,
@datasrc = <font color="#9933CC">'P4W2K'</font>
<b>GO</b>
<br>
<font color="#008080">-- Schritt 2: Login-Information für die SQL Server-Anmeldung beim Linked Server einrichten
-- Parameter:
-- a) @rmtsrvname = Der von sp_addlinkedserver zugewiesene virtuelle SQL Server-Name
-- b) @useself = Keine Windows-Authentifizierung verwenden
-- c) @rmtuser = Benutzername des gelinkten MS SQL Servers (Ziel-Server)
-- d) @rmtpassword = Passwort des Benutzernamens »@rmtuser«</font>
<br>
<b>EXEC</b> sp_addlinkedsrvlogin
@rmtsrvname=<font color="#9933CC">'ZielServer'</font>,
@useself=<font color="#9933CC">'false'</font>,
@rmtuser=<font color="#9933CC">'sa'</font>,
@rmtpassword=<font color="#9933CC">'geheimesPasswort'</font>
<b>GO</b>
<br>
<font color="#008080">-- Schritt 3: Server-Optionen konfigurieren (Beispiel RPC OUT)
-- Parameter:
-- a) Der von sp_addlinkedserver zugewiesene virtuelle SQL Server-Name
-- b) Option »rpc out« selektiert das Ausführungs-Recht für Prozeduren
-- c) Wert »on« aktiviert die unter b) definierte Option</font>
<br>
<b>EXEC</b> sp_serveroption <font color="#9933CC">'ZielServer'</font>,<font color="#9933CC">'rpc out'</font>,<font color="#9933CC">'on'</font>
<b>GO</b>
<br>
<font color="#008080">-- Schritt 4: Zur Kontrolle die Situation prüfen</font>
<br>
<b>EXEC</b> sp_helpserver
<b>GO</b>
</pre>
Der Weg über den linked Server hat auch den Vorteil, dass die Ausgangsdatenbank die SQLs direkt auf den virtuellen Servernamen abschicken kann, d.h. es gibt dann keinen Unterschied mehr zu Zugriffen auf lokale Datenbanken

Hier ein Tip. wie es in "SQL-Server 2005/Windows XP" garantiert funktioniert:
1. Treiber("vfpoledb.exe" - "Microsoft OLE DB Provider for Visual FoxPro") von MS downloaden und installieren
2. In SQL-Server Managment Studio auf SERVER OBJECTS/LINKED SERVERS mit
rechter Maustaste auf NEW SERVER gehen
3. "Q1" , "Z1.dbf" und "C:\db\basis20\dat" sind meine Beispiels-Daten (also nicht abschreiben(!))
4. folgende Einträge (natürlich alles ohne quotes/Anführungszeichen)
- Button OTHER DATA SOURCE
- in LINKED SERVER "q1"
- in PROVIDER "Microsoft OLE DB Provider for Visual FoxPro" auswählen
- in PRODUCT NAME "dbase"
- in DATA SOURCE "C:\db\basis20\dat"
- in PROVIDER STRING "dbase IV"
- LOCATION und CATALOG bleiben leer
- mit OK alles abschicken
5. SELECT für die Datei "Z1.dbf" im Verzeichnis "c:\db\basis20\dat":
"select * from q1...z1", wobei die 3 Punkte zwischen "q1" und "z1" lebenswichtig sind.
6. Im Dateiformat gibt es keinen Unterschied zwischen dBase IV und dBase 5.0
7. Ein möglicher Fehler kann hier noch passieren:
Das Ganze klappt nicht, weil womöglich die Index-Datei (z1.mdx) fehlt oder korrupt ist.
Einfachste Lösung hier: Byte 13 (oder wars 28) im Header von z1.dbf auf Null setzen- google hierzu z.B.: "Swiss +DelphiCenter" oder "ABOUT +Delphi +dbaseheader" oder gucke bei Andreas Kosch: http://entwickler-forum.de/showthread.php?t=18541
8. dBase lebt:
wir haben gigantische Datenbestände (25 Jahre Aufmaß + Bauabrechnung) in dBase (24.11.2007) und bearbeiten die auch zum größten Teil mit dbase-Programmen, die prima und rasend schnell im DOS-Fenster von XP laufen (config.nt: "Files = 99")
Für dBase Interessierte: Programme natürlich in dBase 5.0
9. Wer außer MS braucht Windows Vista?

[hmx]

linked server für dBase IV (und 5) nachgereicht

Hallo zusammen!

nach nochmaligem Test stelle ich fest, dass das MDX-Flag (byte 28) immer auf Null gesetzt sein muss - nicht nur wenn die MDX-Datei fehlt oder unbrauchbar geworden ist.
Sonst aber flutscht das Ding.
Aprospos: ich hab die oben zitierte "KILLmdx"-Procedure von Andreas Kosch nachgebaut - funktioniert prima.
hm

[hmx]

2. Nachtrag von Hm zu linked server +dbase:
Spannend wäre jetzt natürlich, wenn man Byte Nr. 28 auch innerhalb von SQL auf Null setzen könnte - das wäre eine sehr elegante Lösung

[hmx]

3. Nachtrag und Schluss zu linked server + dbase + "vfpoledb.exe "- "Microsoft OLE DB Provider for Visual FoxPro"

AlsoResultat: Es gibt Inkompatibilitäten zwischen (Visual) Foxpro und dBase
1. Index - Lösung: Byte 28 auf 0
2. Memo-Felder: Meine Lösung (= bei meinen Dateien macht das nichts): Memofelder in dBase löschen
3. Datums-Felder: Lösung: in dBase löschen

Naja: wer viel Datumsfelder hat, muß wohl einen anderen Weg gehen.
Mir aber hilft die ganze Geschichte, weil ich jetzt blitzschnell riesige Dateien von dBase zum SQL Server schaffen kann mit allen SQL-Annehmlichkeiten.
Z.B kann ich jetzt mit SELECT INTO ... FROM ... WHERE ... HAVING direkt auf dBase-Dateien zugreifen und neue SQL-Server Tabellen erzeugen.

hm, 27.11.07

[hmx]

vfpoledb 1000 mal schneller als Jet.Ole

Warum ich mir hier die Finger wund schreibe: Der vfpoledb ist ca. 1000 mal schneller als der alte Jet-Ole-Treiber für dBase.
Meine obige Mitteilung (PROVIDER STRING "dbase IV") ist Quatsch natürlich muss es "dbase 5.0" heißen. Denn bei PROVIDER STRING "dbase 5.0" kein Problem mit dem Datum, wenn es dbase 5-Dateien sind. Das mit dem Index ist null Problem (siehe oben)- was noch bleibt, sind die Memo-Felder. Hier Fehlermeldung: "...must open exclusively.. reorder/recreate memo-field (oder so ähnlich)"
Das ist noch zu lösen - also strengt euch an!
Hm 1.12.07