Script-Fehler "system call is too small"

[JohnDoo 10]

Hallo Scripter!

 

Ich habe folgendes kleines (gekürztes) VB-Script:

 

Set oMaster = CreateObject("PrintMaster.PrintMaster.1")
Set oCon = CreateObject("ADODB.Connection")

For Each oDriver In oMaster.Drivers(sServer)
   WScript.Echo "DriverName    : " & oDriver.ModelName
Next

Set oMaster = Nothing

 

Über das Script möchte ich die Drucker eines Druckservers auslesen und in einen Access-DB schreiben. Die Verbindung zur Access-DB ist noch nicht vollständig implementiert.

 

Wenn ich das Script, so wie es oben steht, mit "cscript script.vbs" in einer Shell ausführe, bekomme ich die Fehlermeldung "The data area passed to a system call is too small".

 

Sobald ich die Zeile

Set oCon = CreateObject("ADODB.Connection")

auskommentiere, läuft das Script ohne Fehler und listet mir die Druckermodelle auf.

 

Woher kommt der Fehler "The data area passed to a system call is too small"?

Und wie bekomme ich diesen weg?

[d.stegemann 10]

Hallo JohnDoo,

 

Enumerating Printer Drivers Help Please gibt einen Hinweis Richtung COM Implementierung.

 

Als Lösung wird wmi vorgeschlagen.

 

List Printer Drivers

 

Vielleicht wäre auch ein Ansatz die Daten in ein Array einzulesen und die Datenbankverbindung erst nach Zersörung des oMaster zu machen in etwa so...

 

Set oMaster = CreateObject("PrintMaster.PrintMaster.1")
i = 0
For Each oDriver In oMaster.Drivers(sServer)
   aMname(i) = oDriver.ModelName
i = i+1
Next

Set oMaster = Nothing

Set oCon = CreateObject("ADODB.Connection")
for z = 0 to i step1 ...

 

Ist jetzt aber nur Pseudocode ;)

 

 

Gruß

 

Dirk

[Cybquest 36]

Hab grad das hier ergoogelt:

FIX: The "Data area passed to a system call is too small" error message is logged when you call the CreateEx method at the same time in a multiple-thread application that uses the Virtual Device Interface feature of SQL Server 2000

 

Vielleicht was Hilfreiches dabei?

[JohnDoo 10]

@d.stegemann

Das mit dem Zwischenspeichern in Arrays werde ich mal versuchen. Ich melde mich dann dazu wieder...

 

@Cybquest

Der Hotfix bezieht sich anscheinend nur auf SQL Server 2000. Ich will aber per VB Script in eine ganz normale Access-DB schreiben. Somit hilft mir der Hotfix nix. Trotzdem danke.

 

---

 

Interessant:

Bisher habe ich das Script immer nur auf einem WinXP-Client gestartet und dabei den Fehler erhalten.

Nun habe ich das Script auf einem Win2k3-Server laufen lassen. Und da läuft es ohne Fehler durch! Komisch... Auf dem Server ist noch nicht einmal ein Office oder so installiert.

 

Was könnte zwischen XP und Win2k3 der Unterschied sein?

[Cybquest 36]

Ah... ok, so genau hab ich den Artikel nicht durchgelesen ;)

 

Geht denn ein "Create(ADODB..." überhaupt? Also in einem kpl. leeren Script nur diese Zeile?

 

Die Frage wäre vielleicht auch, welche Version der MSADO-Library du nutzt.

[d.stegemann 10]

Ah... ok, so genau hab ich den Artikel nicht durchgelesen ;)

 

Geht denn ein "Create(ADODB..." überhaupt? Also in einem kpl. leeren Script nur diese Zeile?

 

 

JA..

 

Dim SqlConn, oFSO
Set SqlConn = CreateObject("ADODB.Connection")
MsgBox "kreiert"
Set SqlConn = Nothing
Set oFSO = Nothing

 

gerade probiert(2000 pro), da vorher noch nie getestet :)

 

 

Gruß

 

 

Dirk

[Cybquest 36]

?!? ... ich meinte eigentlich den TO. DER hat ja das Problem ;)

Dass ein Create alleine i.Allg. geht, weiß ich schon. Bei mir gehts unter W2K, XP...

Daher die Frage nach der MSADO-Version.

[JohnDoo 10]

@Cybquest

Wie d.stegemann schon geschrieben hat, ein separates ADODB-Objekt anlegen funktioniert ohne Fehler...

 

@d.stegemann

Der Workaround mit dem Zwischenspeichern der Werte in einem Array und danach erst in die Access-DB schreiben funktioniert.

 

---

 

Tja, jetzt stellt sich halt die Frage: Welchen Weg gehe ich?

Nachdem man im voraus immer nicht weiß, wieviele unterschiedliche Druckermodelle auf einem Server sind, muss man zuerst die Anzahl ermitteln, damit man danach das Array entsprechend re-dimensionieren kann. Das ist halt etwas umständlich, funktioniert aber...

Die Variante, die auf dem Server läuft und bei der beide Objekte gleichzeitig verwendet werden können, wäre diesbezüglich wesentlich eleganter...

 

---

 

Übrigens:

Die Fehlermeldung "The data area passed to a system call is too small" in meinem obigen Script bezieht sich immer auf die Zeile, in der die "For Each"-Schleife stehtund kommt nicht (!) beim Anlegen des Objekts. Das hatte ich vorher vergessen zu erwähnen und vielleicht hilft es ja weiter. Habe ich da etwas falsch gemacht? Sollte aber nicht sein, weil das Script ja auf dem Server so läuft...

Fällt hierzu noch jemandem etwas ein?

[d.stegemann 10]

Hallo JohnDoo

 

das ist ja schonmal erfreulich, das es klappt...

du hast aber schon an die Möglichkeit gedacht das Array mit Redim anzulegen und dann mit Redim Preserve zu redimensionieren?

 

Ansonsten probier einfach mal den WMI Weg. Im Scriptcenter steht, das das unter XP und W2K3 läuft...

 

Gruß

 

Dirk

[JohnDoo 10]

Hallo Dirk.

 

Ich lege momentan das Array an, ermittle über eine Schleife die Anzahl der Druckermodelle, re-dimensioniere das Array mit Redim und schreibe dann wiederum über eine Schleife die Daten ins Array.

 

WMI scheidet aus, weil man damit nicht die virtuellen Nodes eines Clusters auslesen kann. WMI geht immer nur auf die physikalische Maschine bzw. einen Standalone-Server.

 

Ich frage mich halt nur, warum das Script, das auf dem Server läuft, auf dem Client bei der "For Each"-Schleife diesen Fehler bringt. Sind da Buffers zu niedrig oder gibt es Speicherprobleme oder... Sowohl auf dem Server als auch auf dem Client ist der WSH 5.7 drauf.

 

Fällt dir dazu evtl. noch etwas ein?

[d.stegemann 10]

Morgen JohnDoo,

 

Ich lege momentan das Array an, ermittle über eine Schleife die Anzahl der Druckermodelle, re-dimensioniere das Array mit Redim und schreibe dann wiederum über eine Schleife die Daten ins Array.

Gehhst du also zweimal durch die For Each Schleife?

Das ließe sich, denke ich, eleganter lösen. Wenn du gleich einen Counter mitzählst und dann bei i-1 redimensionierst sollte das auch klappen.

 

WMI scheidet aus, weil man damit nicht die virtuellen Nodes eines Clusters auslesen kann. WMI geht immer nur auf die physikalische Maschine bzw. einen Standalone-Server.

Das ist das erste Mal, das du das böse Wort sagst "Cluster" ;)

Ich frage mich halt nur, warum das Script, das auf dem Server läuft, auf dem Client bei der "For Each"-Schleife diesen Fehler bringt. Sind da Buffers zu niedrig oder gibt es Speicherprobleme oder... Sowohl auf dem Server als auch auf dem Client ist der WSH 5.7 drauf.

 

Fällt dir dazu evtl. noch etwas ein?

 

Sorry, da muss ich im passen. Bin dazu im Moment Ideenlos..

Vom Code her sieht das eigentlich gut aus, aber...

 

Gruß

 

Dirk

[JohnDoo 10]

Hallo Dirk.

 

Gehhst du also zweimal durch die For Each Schleife?

 

Ja, so bin ich vorgegangen. Habe das Script jetzt aber angepasst und arbeite nur noch mit einer Schleife. In dieser re-dimensioniere ich das Array mit "ReDim Preserve". Das klappt ganz gut. Danke für den Tipp.

 

Das ist das erste Mal, das du das böse Wort sagst "Cluster" ;)

 

Ich kann es auch nicht ändern... :o

 

 

Ideal wäre jetzt noch, wenn man irgendwie den Grund für die Fehlermeldung herausfinden würde...

 

Nichtsdestotrotz möchte ich mich an dieser Stelle für die super Hilfe bedanken.

[Cybquest 36]

Vielleicht doch einfach mal die Versionen der entspr. Bibliotheken (ado..., print...) vergleichen bzw. der DotNet-Versionen.

[JohnDoo 10]

Ähm..., da muss ich jetzt leider passen.

Wie findet man am schnellsten und einfachsten die verschiedenen Versionen heraus?

So tief stecke ich da leider nicht im Thema...

[Cybquest 36]

DotNet-Version:

How to determine which versions of the .NET Framework are installed and whether service packs have been applied

 

Bei den Bibliotheken auf die entspr. DLL Rechtsklick - Eigenschaften - Details

(Z.B. bei oledb.dll oder oledb32.dll, printadmin.dll...)