powersakthi has asked for the wisdom of the Perl Monks concerning the following question:

Hi All,
I have a perl script which scans for multiple folder and check if any file is dropped in that folder and then it read the contents of the file and then convert the contents as xml and output the file as output.xml and then this perl exe will call a vb exe. The purpose of vb exe is to read the xml and then call a MS-SQL 2000 Stored procedure with this xml as input.
My Question:
1) Is it best to use vb to connect to MS-SQL and then call Stored Procedure with the xml or anyother best at par solution is available in Perl itself.
2) When i run the perl script with around 10 files by commenting without the script calling the vb exe it just takes 2 seconds but when i call vb exe uncommentinternally from the perl and then run the perl script it takes 25 seconds. But when i run the same vb exe individually it takes less than 1 second to update a single xml.
Please help me to sort out this issue...
Thanks in advance! Please let me know if any other information need to be published!!!

The Source Code i have done till now is here http://www.nopaste.com/p/apWkW79Cy/txt

  • Comment on Running VB Exe from perl takes lot of time

Replies are listed 'Best First'.
Re: Running VB Exe from perl takes lot of time
by erroneousBollock (Curate) on Sep 15, 2007 at 04:23 UTC
    Ditch the VB ;)

    You can connect to the MSSQL database via the DBI module with the DBD::ODBC driver.

    You just use DBI; at the top of your script, and call DBI->connect() with the connection string formated as described in the DBD::ODBC documentation.

    DBI is the way the vast majority of perl programs connect to databases, so it's a good library to learn.

    PS: It's probably best not to use colour in your post unless you need to point out something that has to do with colours.

    -David

[reply]
[d/l]
[select]
Re: Running VB Exe from perl takes lot of time
by swampyankee (Parson) on Sep 15, 2007 at 16:28 UTC

    The problem isn't in Perl per se; I suspect it's in the overhead in starting an external process. You don't see that overhead when running your VB procedure from the IDE or from a command shell.

    The best solution to this is to use DBI; this eliminates the overhead associated with external processes.

    emc

    Information about American English usage here and here.

    Any Northeastern US area jobs? I'm currently unemployed.

[reply]
      Hi All, thanks for your replies... I have modified the flow by vb calls perl and perl does the parsing then generates xml and then vb updates the xml to db... Thanks
[reply]
ODBC Driver for DBI does not support all MSSQL Data Types
by brainbuz (Novice) on Oct 01, 2007 at 13:41 UTC
    I'm struggling with a problem with the ntext datatype which doesn't work the odbc driver for dbi. If the database is yours, then you can just choose not to use that data type, but the database I'm trying to work with is not mine and I can't change data types. Unless I find an answer my solution will be to either query it in vbs (in which case I may as well bite the bullet of doing the whole script in vbs) or call the osql program to read / update fields that break dbi.
[reply]

Back to Seekers of Perl Wisdom