PerlSvc Blues...

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

As luck (if such a thing exists) would have it, this weekend I am writing a quick program to monitor a table in a database (processing queue for one of our products - on SQL7). With that, said program must run on an NT 4.0 box. However, the SysAdmins don't want to install Perl. I have two choices, then -- one) run the program remotely. two) make a freestanding program with the PDK (Perl Development Kit) from ActiveState (using PerlApp or PerlSvc).

I decided to take option two. Now, keep in mind that the program works already... remotely. I just want to take and "compile" the program. So, I put the code into the format required by PerlSvc. I run
PerlSvc -v -r -s QCheck.pl -e QCheck.exe -f
The code "complies" fine. I run QCheck.exe -install and the program installs fine as a NT service. When I start the program from the services menu, I become frustrated. The program starts and fails. After some tracing, I find that the program dies on the DBI->connect (It took me a second to find because I have no idea where the die information is found). So, I read up on PerlSvc and PDK and find that there is little to NO help on the subject. I did narrow it down to the fact that DBI is calling DBD::ODBC at runtime and the module is not included at compile time. To try and fix the problem, I added the -a switch to my build and added the DBD::ODBC .dll... still no luck.

Has anyone had luck using PerlSvc to create a freestanding executable (that uses DBI)?!? I have also heard that using Tk with PerlApp is difficult, also.

Any help is appreciated.
Casey

Comment on PerlSvc Blues... Select or Download Code

Replies are listed 'Best First'.
Re: PerlSvc Blues... by !me (Acolyte) on Jul 16, 2001 at 03:05 UTC
You can try adding the following to the begining of your script. use lib 'c:/perl/lib'; then recompile and run, if it works you probably need to copy the DBD / DBI module folders along with your exe. I usually create a sub folder called lib and drop all the required external files ( modules and dll's ) in that folder then I reference back to it using use lib 'INSTALL_FOLDER/lib'; Dont forget about the auto folders that contain the dll's. btw- I use Perl2exe ( which works great for me )	[reply]
Re: PerlSvc Blues... by jplindstrom (Monsignor) on Jul 16, 2001 at 02:39 UTC
The general workaround to force modules into a PerlApp (and I guess PerlSvc) application is to do it manually somewhere in your code. So just put `#Foce load for PerlApp's sake use DBD::ODBC;` [download] somewhere. DBD::ODBC might use other "implicit" modules as well. /J Update: Misread "-a switch to my build and added the DBD::ODBC .dll" to mean that you used -a to add the .dll file. I guess the -a should do it, so if my suggestion works (it shouldn't), please let me know ;)	[reply] [d/l]
Re: PerlSvc Blues... by ckohl1 (Hermit) on Jul 16, 2001 at 04:29 UTC
I do not have much to report in the way of DBD::ODBC, but I am here to tell you that Win32::ODBC works very well on Windows NT. It also compiles and plays nice with Tk using PerlApp and PerlSvc. Chris 'You can't get there from here.'	[reply]
Re: PerlSvc Blues... by Mungbeans (Pilgrim) on Jul 16, 2001 at 14:16 UTC
This may be a windows service "feature". Depending on how the service is set up you may be unable to use network resources (e.g. connecting to a database on a remote server, seeing some network drives). Check your service setup, if it is using the default account this could be the problem. Reconfigure it to use your login and password and it should work. Except that is unbelievably ugly for distributing applications... Anyway test this with a simple application first. I have run into a couple of pieces of software that absolutely refuse to run as services. In those cases I set up a server program that is always running listening for requests on a specified port. The perl service connects to the network socket and requests that the server program runs the buggy executable. /msg me if you want some advice - the code is not even gamma quality, it is hideously insecure so it's not reuse ready. Ugly, ugly, ugly. "The future will be better tomorrow."	[reply]
Re: PerlSvc Blues... by fmogavero (Monk) on Jul 16, 2001 at 23:33 UTC
I'm right there with you bitwise. Please check out this before going any further. I had a similar problem. I was using PerlApp. The problem that I ran into in my code was actually something that wasn't very clear to me after rtfm'ing. In the code I have `DBI::ODBC` as a string. In the documentation they say that if you use a scalar like `use $varrepresentinglib` or `require $varrepresentinglib` it will not compile because PerlApp does not parse use statements. It also does not parse modules you are using when you call another module via a scalar. Since `DBI::ODBC` was contained in a scalar value, PerlApp never picked up it needed `DBD::ODBC`. The solution to my problem was to add `-a DBD::ODBC` at compile time. As far as NT Services go, I learned in my NT Admin assignments that services are fickle beasties. Can you use the AT command to schedule an EXE to run instead of a service? Does it need to be a service?	[reply] [d/l] [select]
Re: PerlSvc Blues... by lostcause (Monk) on Jul 17, 2001 at 01:28 UTC
Probably not the answer in this case but a useful point to note: I created a free standing PerlSvc that worked once while I was logged in and always failed once I had logged out. The problem was fixed once the "allow service to interact with desktop" option in the services control panel - log on tab was unchecked. Cheers Richard	[reply]