Also, I would suggest just using Perl for all of it, depending on what the rest of the VBA code is doing.

Anyhow. Calling perl installed on the Windows machine is realtively easy, use the VBA 'Shell' function to run the executable, and pass it whichever parameters you want with the script name. Calling perl on a remote machine involves knowing how you would do it by hand. You can either install it as a CGI, and use the HTTP VB objects to simulate surfing there. Or you attempt to run the perl executable 'by hand', by logging in remotely, with telnet for example. (VB might have a control for that, or you'll need the socket control).

You could also Shell out to plink.exe (part of the putty suite of ssh tools) and run a remote command that way. docs

Other than that, its hard to give advice.. To programmatically do something like this, you first have to know how you would do it by hand..

C.

If you go with the Active Perl Method, you should give Spreadsheet::ParseExcel and Spreadsheet::WriteExcel a look. They are both available from the ActiveState PPM and CPAN. The only drawback to WriteExcel is that it can not write to an existing file, so you will have to write the entire workbook each time.

Greg W

Thanks to everyone for their replies.

It seems to me that there are two main branches of solutions for me. One is to set up a web server on the linux box and use my perl script as a CGI. I would appreciate it if somebody could provide some sample code on using the HTTP VB objects within VBA to call a script on the linux box.
I think one question that I need to find out is how do I go about finding out if I am able to make http requests from within VBA?

After, being able to proceed through this CGI path what points or examples should I consider when thinking about security?

This CGI option seems to be suitable for me since I already have a linux web server set up and one of the reasons I want to keep perl on the linux server is that users of the application do not need to have perl installed on their computer.

The other option that seems to be popular is the use of ODBC. I have found from some sources that if I go through this ODBC route that I would need to install perl on the windows side. Is this true?




What would be the deciding factors in figuring out which route to go whether it be using CGI or ODBC? Basically in the application I want to develop would allow a user within Excel will have a worksheet and be able to press a button to start a process where one column in the worksheet will be sent to query the mysql database to retrieve about six columns of data to update the Excel worksheet. As well, about two of the columns will be used to update the mysql database. Sometimes the columns will be about 30 rows but it is possible that I will be working with about 10 000 rows. I am concerned about speed but I think that the slowness could possibly be obviated by precomputing the sql queries and placing the values in a table since I already know what the queries will be most of the time.

thanks very much

PerlCtrl -t > xlsls.ctrl
[download]

package MyControl;

use Net::Telnet;

sub doit {
    my $t = new Net::Telnet(Timeout=>500);
    $t->open("lin.ux.box.ip") or die $!; # 
    $t->login("user id","password");
        # replace ls -al below with /usr/bin/perl as reqd
    chomp(my @oldls = $t->cmd("ls -al")); 
    my $lsstr = join "\n", map { $_ . ") " . $oldls[$_] } (0  .. $#old
+ls);
    $t->close();
    return $lsstr;
}
[download]

    PackageName     => 'MyControl',
    ControlName     => 'MyVeryOwnControl',
    ControlVer      => 1,  # increment if new 
    ProgID          => 'My.Control',
    LCID            => 0,
    DefaultMethod   => 'doit',
    Methods         => {
        'doit' => {
        RetType             =>  VT_BSTR,
        TotalParams         =>  0,
        NumOptionalParams   =>  0,
        ParamList           =>[ ]
        }
    }, # end of 'Methods'
    Properties => {
        
    }, # end of 'Properties'
[download]

PerlCtrl xlsls.ctrl
[download]

Created 'xlsls.dll'
[download]

regsvr32 xlsls.dll
[download]

Sub unrun()
    Dim objMyControl
    Set objMyControl = CreateObject("My.Control")
    'testing the result of our unix listing/command
    MsgBox objMyControl.doit
End Sub
[download]

Easiest way is set up and ODBC driver to connect to the mysql database. VBA lets you query ODBC so you can program in the queries and bypass the perl script.

• Reference 1
• Reference 2

If there are functions in the perl script you can not do in VBA you could install Active State Perl on the Windows Machine and use perl to via ODBC to connect to the Linux Box, process the data and use Win32::OLE to control Excel, or to use Excel::Template moduels to create the data structure. It all really depends on what you are doing with the data.

I think the description you have your best bet would be to use the mySQL ODBC drivers and use straight vba.

I feel sick from uttering those words.