I've also run into the "Can't load DLL" problem sometimes, but in those cases always appeared a popup dialog telling me the name of the DLL that was missing (e.g. icuuc32.dll).
Apparently that message is also logged in the system events, so you might take a look into the Windows Event Viewer messages (in the "System" section. Thilo HEWITT, DARRYL wrote: > Thanks, Thilo! > > Oddly enough, the Path on DSMRDCRD02, where ARS.dll does NOT load, has > "E:\Remedy\AREmail\dsmrdcrd02" and "E:\Remedy\pluginsvr". The Path on > DSMRDCRD03, where ARS.dll does load, has "E:\Remedy\AREmail" and > "E:\Remedy\pluginsvr". > > The ar dll's are in these locations. The icu...32.dll files are in the > AREmail locations as well. These are the only locations in the Path > variable that have these files. > > I copied the arxxx70.dll files to the "E:\Remedy\AREmail\dsmrdcrd02" > folder but that made no difference. > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Thilo Stapff > Sent: Wednesday, March 05, 2008 9:21 AM > To: ARSperl User Discussion > Subject: Re: [Arsperl-users] ARS 1.90 Can't load ARS.dll > > > -- The DLLs need to be in a directory that is contained in your system's > > PATH variable, exactly as if they were .exe files. > > -- The user tool itself is not needed. > > -- You might, however, need the icu...32.dll files from the user tool > directory. > > > Thilo > > > HEWITT, DARRYL wrote: >> I am still getting "Can't load 'E:/Program >> Files/Perl/site/lib/auto/ARS/ARS.dll' for module ARS: load_file: >> The specified module could not be found at E:/Program >> Files/Perl/lib/DynaLoader.pm line 229". >> >> What I have done since our last email exchange: >> >> 1) Deleted and re-installed ARS Perl package just to make sure I had >> done it correctly. >> (DOS commands and results are attached) >> >> 2) Copied arxxx70.dll's to the root folder where our Remedy AR Server >> was installed. >> >> 3) Ran perl -MARS -e "print $ARS::VERSION" to test and received the > same >> error. >> >> 4) After checking the registry, I tried to register dll's with >> REGSVR32 "E:\Program Files\AR System\User\arapi70.dll" >> but received error: >> >> >> 5) Rather than mess with figuring out the dll registration issue, I >> installed Remedy User 7.0.1 >> since I had found registry settings in >> >> > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDll's > >> folder >> for "E:\Program Files\AR System\User\arapi70.dll" on the server > that >> works. >> Remedy User 7.1 was already installed on this server. >> >> 6) Ran perl -MARS -e "print $ARS::VERSION" to test and received the > same >> error. >> >> All of the above raises some questions that I hope you will answer. >> >> -- Where is ARSPerl expecting to find the Remedy API's? >> >> -- Does the Remedy User for the correct version need to be installed > on the >> server, or PC, running the Perl package? Does this also need to be > >> run where >> AR Server is installed? >> I had always assumed that ARSPerl was basically mimicking someone > running >> Remedy User. >> >> -- We have been using ARSPerl since 2002 and it has worked well. >> However, all I have ever done when moving the location of the Perl >> scripts >> is make sure that the following 3 dll's were present in the Perl > scripts >> folder for the Perl script issuing the "USE ARS": arapixx.dll, >> arrpcxx.dll, and arutlxx.dll. >> Is this all that really needs to be present? >> >> To repeat some of my previous, we have two Windows 2003 SP1 servers: >> DSMRDCRD02 and DSMRDCRD03. >> >> I have installed the ARSPerl 1.90 package on both using the same > procedure. >> >> Running the DOS command line perl -MARS -e "print $ARS::VERSION" works > >> on DSMRDCRD03 >> but receives the load failure error on DSMRDCRD02. >> >> DSMRDCRD02 was built with the Remedy AR software from scratch, i.e. > new. >> >> DSMRDCRD03 was built with the Remedy AR software as an upgrade over an > >> existing install of version 7.0.1. >> >> Any help or suggestions would be greatly appreciated. >> >> > ------------------------------------------------------------------------ >> *From:* [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] *On Behalf Of *jeff murphy >> *Sent:* Tuesday, March 04, 2008 8:12 AM >> *To:* ARSperl User Discussion >> *Subject:* Re: [Arsperl-users] ARS 1.90 Can't load ARS.dll >> >> Yes, you'll need to use the same revision of the API that the perl >> module was compiled against. The good news is that, from a perl script > >> perspective, it doesn't matter if you use a 7.0 API against a 7.1 >> server, or even a 6.3 API against a 7.1 server. There are only a few >> edge cases that you might hit against (currency fields iirc) but in >> general you should be OK. >> >> jeff >> >> >> On Mar 4, 2008, at 11:05 AM, HEWITT, DARRYL wrote: >> >>> Thanks for your quick response! >>> >>> Yes, ARS.dll does exist at E:\Program Files\Perl\site\lib\auto\ARS. >>> >>> I have a theory that I would like to run by you. Does the Perl code >>> version check the ARS api's when the USE clause is executed? >>> >>> On the server that is not working, we have installed and are running >>> AR version 7.1 (arxxx71.dll's). >>> >>> On the server that works, we have installed AR version 7.1 >>> (arxxx71.dll's) but >>> there also exist arxxx70.dll's, arxxx63.dll's, and arxxx51.dll's. I >>> won't even try to >>> explain how that happened but could that be affecting the load of > ARS.dll? >>> >>> I realize that ARS 1.90 was written to AR version 7.0.1. Does that >>> mean it will not work with AR version 7.1? >> >> > ------------------------------------------------------------------------ >> > ------------------------------------------------------------------------ > - >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> Arsperl-users mailing list >> Arsperl-users@arsperl.org >> https://lists.sourceforge.net/lists/listinfo/arsperl-users > > > ------------------------------------------------------------------------ > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Arsperl-users mailing list > Arsperl-users@arsperl.org > https://lists.sourceforge.net/lists/listinfo/arsperl-users > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Arsperl-users mailing list > Arsperl-users@arsperl.org > https://lists.sourceforge.net/lists/listinfo/arsperl-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Arsperl-users mailing list Arsperl-users@arsperl.org https://lists.sourceforge.net/lists/listinfo/arsperl-users
