HTML::Template causing odd ODBC error in output

[1DMF]

Hi,

I seem to be getting an odd error output in my template

[Wed May 28 16:24:07 2014] financial_promotions.pl: 	(in cleanup) Goto undefined subroutine &AutoLoader::AUTOLOAD at C:/Perl/lib/Win32/ODBC.pm line 867.
[Wed May 28 16:24:07 2014] financial_promotions.pl: 	(in cleanup) Goto undefined subroutine &AutoLoader::AUTOLOAD at C:/Perl/lib/Win32/ODBC.pm line 867.

I cannot reproduce the error with a script accessing the same data and outputting to screen.

As soon as I use HTML::Template that error is embedded in a random place in the outputted HTML?

Any ideas why?

Thanks,
1DMF

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[1DMF]

Well it seems to be a warning being produced by Win32::ODBC and output by the HTML::Template.

Neither author is contactable or interested in supporting their modules, so I have refactored to use DBI instead and the error has gone away.

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[MikeLacey]

Neither author is contactable or interested in supporting their modules

That's a shame - good detective work on your part though

Mike

 

[1DMF]

Yeah, I have been happy using Win32::ODBC for 10 years, and it negates the need to decode Unicode data from MS SQL, which is a problem with DBI as you have to use a codepage to decode any wide chars.

Win32::ODBC author has fell off the grid, even emails on their personal website bounce back as invalid.

HTML::Template author wasn't interested as the error originated from Win32::ODBC, plus they had handed the module over to a.n.other some time ago.

The Perl / Catalyst community believe I should be using DBIC and Template::Toolkit anyway, so I guess at some point another refactor will be required!

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[audiopro]

I use HTML::Template a lot and have never seen that error, when do you get it?

Keith

http://www.studiosoft.co.uk

 

[1DMF]

It just started to randomly appear on template output I had been coding as HTML5, I never traced exactly what was screwing it up but I think it was related to either the new HTML5 tags or attributes, though it's weird replacing the DB module solved the problem.

The warning is in Win32::ODBC but was being output in the HTML::Template, the problem went away when I replaced Win32::ODBC with DBI. I never looked any further into the root cause as I solved the problem with DBI.



"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[audiopro]

I have always used DBI, so that is why I didn't see the error.

Keith

http://www.studiosoft.co.uk

 

[1DMF]

Touché! - but that brings with it its own headache with Unicode chars from MS SQL as it's CP1252 not UTF-8.

Wouldn't it be nice if just once things were truly platform independent!



"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[audiopro]

I have never had a problem with any odd code in MySQL although I tend to filter out anything that isn't basic text or punctuation.


Keith

http://www.studiosoft.co.uk

 

[1DMF]

Yes, MySQL seems fine with UFT-8, I don't have a problem with DBI and PostGreSQL either, it's just M$ SQL due to the way M$ store Unicode data with an old CodePage encoding.

I find it odd that £ isn't part of ASCII, it used to be '#' which USA call pound, but in Perl if you

my $var =~ s/[^[:ascii:]]//g;

the £ seems to get stripped?

Not sure there is a regex shorthand for extended ascii is there?

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[audiopro]

I have never done anything with M$ SQL, I always used FoxPro for my local database needs and it has served me really well.

The £ issue has been a nightmare but only on one particular server from the one ISP.
Over the years I have had quite a number of servers and VPS's from that ISP but this particular one has caused me endless problems since a website was ported to the 'new improved' server back in March. The £ sign has always been part of the extended charset chr(163) and has never been an issue. The fact that the ISP's own support pages cannot display them correctly only reinforces the fact that it is they who have lost the plot.

It is not an issue any more as on my recommendation, the client in question has signed up with a new ISP and the process of transferring files is underway.



Keith

http://www.studiosoft.co.uk