Guten Morgen zusammen,
ich bin kein Programmierer oder dergleichen und habe von VBA usw. nicht die große Ahnung, weshalb ich hier dringend Hilfe suche:
Folgende Situation:
Wir haben ein Programm, welches die Daten "Stichwort" und "Adresse" an eine Batchdatei übergibt und diese aufruft.
Die Batch-Datei hat folgenden Inhalt:
echo on
start c:\Eingang\alarm.vbs %1 %2
exit
Diese Batch startet die VBS-Datei alarm.vbs, welche folgenden Inhalt hat:
Option Explicit
'// ----------------------------------------------------------------------------------------------------------------
'//
'// ----------------------------------------------------------------------------------------------------------------
Const sFile = "C:\EingangMK\ALARM.accdb"
Const sDBE = "DAO.DBEngine.120"
Const SQL = "Select Stichwort, Adresse From Eingang;"
'// ----------------------------------------------------------------------------------------------------------------
'//
'// ----------------------------------------------------------------------------------------------------------------
dim a, b
dim dbe, db, rs
Dim i
Set a = Wscript.Arguments
Set dbe = CreateObject(sDBE)
if not dbe is Nothing then
Set db = dbe.OpenDatabase(sFile)
if not db is Nothing then
Set rs = db.OpenRecordset(SQL)
i = 0
rs.AddNew
for each b in a
if i > 8 then exit for
rs(i) = b
i = i + 1
next
rs.update
rs.close
db.close
end if
end if
Set rs = Nothing
Set DB = Nothing
Set DBE = Nothing
Das VBScript soll die Daten "Stichwort" und "Adresse" in die Datenbank eintragen.
Auf einem PC funktioniert das Ganze auch, auf einem anderen, auf dem es funktionieren muss, nicht.
Es kommt zur Fehlermeldung:
Zeile: 17
Zeichen: 1
Fehler: ActiveX-Komponenten kann kein Objekt erstellen:
'DAO.DBEngine.120'
Code: 800A01AD
Quelle: Laufzeitfehler in Microsoft VBScript
Kann mir hier evtl. jemand weiterhelfen? Gibt es vielleicht eine bessere Lösung, um diese Daten per Batch (die Batch muss sein) in die Datenbank einzutragen?
Danke
Beim MSAccess handelt sich um die Version 2013.
Ist die Komponente DAO.DBEngine.120 auf dem fraglichen Rechner installiert?
Grundsätzlich würde ich bei jeder nicht Access Anwendung kein DAO sondern ADO verwenden.
DAO.DBEngine.120 (ACE) kommt eigentlich mit einer Officeinstallation ab Version 2007 daher und sollte vorhanden sein.
Hallo!
Ich tippe auf eine Bit-Problematik.
Es wird vermutlich DAO.DBEngine.120 für 32 bit installiert sein, das Skript aber in 64 bit gestartet werden.
Da nur Daten angefügt werde sollen, würde ich wie bereits von Markus geschrieben, ADODB verwenden.
Falls Access installiert ist, könnte man auch den Umweg über eine Access-Instanz gehen.
ADDOB ist meiner Meinung aber einfacher.
Gruß
Josef
Zitat von: Josef P. am Januar 04, 2024, 13:14:41Es wird vermutlich DAO.DBEngine.120 für 32 bit installiert sein, das Skript aber in 64 bit gestartet werden.
Da nur Daten angefügt werde sollen, würde ich wie bereits von Markus geschrieben, ADODB verwenden.
Der möglichen Ursache stimme ich zwar zu, aber die Schlussfolgerung erscheint mir abwegig. Warum ein funktionierendes Script umschreiben, wenn man es doch einfach im 32bit-Subsystem starten könnte?
Eine weitere Ursache könnte sein, wenn eine C2R (Click to Run) Installation von Access installiert ist. Deren ACE-Bibliothek war lange zeit nicht ausserhalb der Office-Sandbox-Umgebung verwendbar. Bei Access 2013 wäre IMO die einfachste (einzige?) Lösung, das ACE-Redist-Package zu installieren.
PS: Natürlich ist es auch eine Möglichkeit das Script auf ADO umzuschreiben, aber ich würde zuerst die Problemursache ergründen wollen.
PPS: Für ADO braucht man den JET/ACE-OLEDB-Provider. Ist der denn immer verfügbar, auch wenn die o.g. Probleme bestehen?
Hallo,
vielen Dank für die schnellen Hilfestellungen...aber da ich, wie am Anfang geschrieben, von dieser Programmierung nicht so richtig Ahnung habe, brauche ich bitte weitere Tips:
Wie muss ich das Script umschreiben, um die Daten per ADODB einzutragen?
Oder ist das zu kompliziert? Ich benötige den schnellsten und einfachsten Weg.....das Ganze Projekt ist im Übrigen für die ehrenamtliche Arbeit einer Freiwilligen Feuerwehr und ich versuche, hier die Arbeit zu vereinfachen 😁.
Vielen Dank nochmal
Hast du das Problem mit den verschiedenen Bit-Versionen verstanden?
Was ist an dem fraglichen Rechner für eine Access und Bit-Version installiert?
Ich gehe davon aus, dass du falls es daran liegt mit ADO das gleiche Problem haben wirst.
Du kannst ja mal einfach versuchen aus dem Script heraus ein Connection Object mit CreateObject("ADODB.Connection") zu erzeugen.
Du kannst mal versuchen das Script mit expliziter Angabe der jeweiligen Script-Ausführungsumgebung zu starten:
C:\Windows\System32\cscript.exe c:\Eingang\alarm.vbs %1 %2
C:\Windows\SysWOW64\cscript.exe c:\Eingang\alarm.vbs %1 %2Die erste Zeile ist für die native 64bit-Umgebung, die zweite Zeile für das 32bit Subsystem.
Die Argumente für das Script, musst du zum Testen wahrscheinlich durch konkrete Werte ersetzen.
Hallo,
Vor langer Zeit habe folgenden mal von Josef bekommen.
Vielleicht hilft's.
'----- Start: Check 32/64-Bit -----'
'Quelle: https://stackoverflow.com/questions/2806584/how-do-i-run-a-vbscript-in-32-bit-mode-on-a-64-bit-machine
Dim sArg
Dim Arg
Dim sCmd
Dim oWShell
Dim oProcEnv
Dim ScriptHost
ScriptHost = Mid(WScript.FullName, InStrRev(WScript.FullName, "\") + 1, Len(WScript.FullName))
Set oWShell = CreateObject("WScript.Shell")
Set oProcEnv = oWShell.Environment("Process")
'Am I running 64-bit version of WScript.exe/Cscript.exe? So, call script again in x86 script host and then exit.'
If InStr(LCase(WScript.FullName), LCase(oProcEnv("windir") & "\System32\")) _
And oProcEnv("PROCESSOR_ARCHITECTURE") = "AMD64" Then
'rebuild arguments'
If Not WScript.Arguments.count = 0 Then
sArg = ""
For Each Arg In WScript.Arguments
sArg = sArg & " " & """" & Arg & """"
Next
End If
sCmd = """" & oProcEnv("windir") & "\SysWOW64\" & ScriptHost & """" & " """ & WScript.ScriptFullName & """" & sArg
oWShell.Run sCmd
Set oProcEnv = Nothing
WScript.Quit
End If
'----- End: Check 32/64-Bit -----'gruss ekkehard
Hallo nochmal,
vielen Dank für die Hilfestellungen.
Die Lösung in meinem Fall war tatsächlich die falsche Offie-Version: Ich hatte die 32bit-Version installiert. Nach Deinstallation und Neuinstallation der 64bit-Version klappt nun alles.
Vielen Dank