On Sat, 23 Oct 2004 06:22:12 -0400, Marc M. Adkins wrote:
Hi Marc
>>>�I have been getting an annoying warning about dereferencing
>>�an unreferenced
>>>�scalar. �Sometimes it comes out in such a way that it
>>�misses $SIG{__WARN__}
I'm using Perl v5.8.4, although not directly from ActiveState.
See: http://savage.net.au/Perl/html/upgrade-perl-apache.html for details. (Thanx again
Randy!)
Note: I am not convinced switching to this version will solve your problem. I have MS
C++, so I can compile locally.
Also, there is a free command line version of MS C++ available:
-------------------------------
o Command line version of compiler:
- http://msdn.microsoft.com/visualc/vctoolkit2003/
o Just bear in mind that users will need .net framework installed (or at a
minimum MSVCR71.DLL in the path).
-------------------------------
Perl's signal handling under Windows has always been unreliable, although recent
Perl's may have fixed some problems. I never rely on signal handling myself. I wish I
could. You're free to do so, of course!
>�Yesterday (10/22) I found that ActiveState had updated their PPM
>�repository and I downloaded and installed DBI 1.45:
Ahh, but did you really install it? Probably not.
What happens is the the DLL is locked by the OS after being used, eg by running a
program which does 'use DBI;'.
You have to reboot before the DLL is free to be deleted and thus replaced. Here, I can
recreate this error at will. This is a fragment of the output of 'nmake install' (this
output is captured by an unreleased module I wrote which I use to install Perl
modules. ie you may have missed the error msg in the heat of the moment):
Cannot forceunlink C:\Perl\site\lib\auto\DBI\DBI.dll: Permission denied at
C:/Perl/lib/File/Find.pm line 906
NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0xff'
So, reboot and install immediately, ie before running anything (eg a CGI script) which
does 'use DBI;'.
Now let's move on to the problem at hand...
>�Unfortunately, my test program (attached, same as previous version)
>�is still saying the same thing (two runs, second demonstrates
>�problem):
>
>�D:\CaseLaw>c:\temp\unref.pl
>�Step 1: �Database query
>�16392: �db_denydatareader
>�16393: �db_denydatawriter
>�3: �INFORMATION_SCHEMA
>�16384: �db_owner
>�2: �guest
>�16390: �db_datareader
>�16385: �db_accessadmin
>�16389: �db_backupoperator
>�1: �dbo
>�4: �system_function_schema
>�16391: �db_datawriter
>�0: �public
>�16386: �db_securityadmin
>�16387: �db_ddladmin
>�5: �servman
>�Step 2: �Copy files
>�Copied readme.txt
>�Copied shortcut.cpp
>�Copied SHORTCUT.DEF
>�Copied Shortcut.MAK
>�Copied Shortcut300.MAK
My output is slightly different that yours. I don't have this line:
3: �INFORMATION_SCHEMA
for example.
Step 1: Database query
16392: db_denydatareader
16393: db_denydatawriter
16384: db_owner
2: guest
16390: db_datareader
16385: db_accessadmin
16389: db_backupoperator
1: dbo
0: public
16386: db_securityadmin
16391: db_datawriter
16387: db_ddladmin
Step 2: Copy files
Copied odbc.pl
Nevertheless, it works.
The output I get is identical, whether or not I have:
if (@ARGV) {
or
@ARGV = (1);
if (@ARGV) {
to force execution of fetchall_hashref.
So, I can't reproduce the problem you report.
>�This is not a showstopper for me. �I've already modified all of my
>�code to avoid fetchall_hashref(). �Well, almost all of my code, I
>�still see the error from time to time so I must have missed
>�something somewhere...
I feel sure there would be a flood of complaints if the problem were in Perl, DBI or
DBD::ODBC.
I really suspect your particular setup - nothing personal :-).
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 24/10/2004
http://savage.net.au/index.html
