[Thanks for replying Wayne. I hope you don't mind, but I've copied the list back in, in case this discussion is of interest to others and prompts any more feedback!)
Going back to first principles, the basic challenge I have is to produce a perl script that can run on either Windows or Unix to collect information from WMI on various remote Windows systems, and works with free software. (It is very easy for a perl script running on just Windows to read and write WMI data, because it can use Win32::OLE. But that doesn't address the requirement for it to run on Unix.) As I'm not too confident about adapting code at run-time based on the OS, I was trying to find some common access method that would work equally on both Windows and Unix, and ODBC seemed to fit the bill. To answer your question, the open-source unixODBC Project provides ODBC on Unix [see http://www.unixodbc.com/ ], and the WBEM/WMI ODBC Adapter on Windows provides the local ODBC interface to WMI itself. However, so far I haven't even been able to display WMI objects in Microsoft Access (via the WMI ODBC Adapter). It just shows up any WMI 'table' (set of WMI class instances) I define as empty, as if it is displaying just the class definition and no instances (each of which would be a record if it appeared). So for this and other reasons (including that WMI ODBC is read-only, and treats all integers as signed!) I am now thoroughly ticked off and disillusioned with the ODBC route. I am now looking at using RPC (Remote Procedure Call) to call directly into the WMI Scripting Library DLL, wbemdisp.dll, although in view of its likely interminable complexity this is definitely the Doomsday option! So before getting into that, I'm very much hoping someone, or myself, can come up with a simpler 'magic bullet'. (I've also been investigating "OLE DB" and "ADO", although with no high hopes of being able to use or access these from Unix.) All in all it seems a diabolical problem, but well worth the effort if a practical solution can be found. A sound solution must also minimize, preferably to zero, the installation requirements on the target systems. For example, I wouldn't be happy with a bodge solution that requires telnetting to each target windows system and running the Microsoft WMI SDK 'wbemdump' command, e.g.: wbemdump /Q root\cimv2 WQL "select Manufacturer from Win32_SystemEnclosure Anyway, sorry to ramble on. But that is the problem Cheers John R Ramsden ([EMAIL PROTECTED]) com instead of cam -----Original Message----- From: Wayne Simmons [mailto:[EMAIL PROTECTED] Sent: 13 May 2004 15:40 To: John_Ramsden Subject: RE: Retrieving WMI object data via WMI/WBEM ODBC Adapter how did you get ODBC to run on unix? I'm supposed to figure that out, any help you could give would be greatly appreciated. I'm sorry I can't help you with your WMI problem I haven't ever used it. However, I might suggest you step into the ODBC module and perhaps see what it's doing to cause the error... -Wayne Simmons > -----Original Message----- > From: John_Ramsden [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 13, 2004 7:15 AM > To: [EMAIL PROTECTED]; Perl-Win32- > [EMAIL PROTECTED] > Subject: Retrieving WMI object data via WMI/WBEM ODBC Adapter > > > This is driving me nuts! Is there anyone on the entire planet > who has ever actually used Microsoft's WMI ODBC Adapter, > via perl or otherwise ?! > > I am trying to write a perl script to read WMI class instances > via ODBC, in the hope of producing an OS-independent script [*] > that can be run from either Windows or Unix, and ODBC seemed > to be the simplest way to go (although Microsoft's WMI ODBC > Adapter has various limitations, including being read-only). _______________________________________________ ActivePerl mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
