Light, in my experience. I have done it at home and for jfrm a few years back. He was using R any MySQL. I had no issues with the Perl side of either.

Regards,

John Davies

May I ask, just out of curiosity, what weird database are they connecting to? This sounds overcomplicated.

May I ask, just out of curiosity, what weird database are they connecting to? This sounds overcomplicated.

Yes, it does. The usual way to connect to a database would be to use DBI and some DBD::xxx module specific to the database in use. E.g. DBD::Oracle, DBD::Pg, DBD::MariaDB (also for MySQL), DBD::SQLite, or if everything else fails, DBD::ODBC plus the ODBC driver for the database plus an ODBC manager (comes with Windows, something like unixODBC needs to be installed on Unix).

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

If the heart of the requirement is Inline::Java, that works great on Linux, which is probably better for servers (and for sure, cheaper than Windows licences).

It might well then make sense to consider moving off Java to DBI, as afoken says. But it can be done in a multi-stage way.

"They have over a hundred CGI based apps..." -- my recommendation would be to classify said apps into groups and recognize their differences/similarities. I have seen this before -- some sixty apps that appeared too much to migrate. Upon closer inspection over half of them were derived from the same script(!) with only some variables in the top/preamble section that differed. Assess whether it would be too much work to port all of that to modules. Then, as other responses have mentioned, consider whether that centralized code would be best hosted remotely and delivered as a service on Linux or similar.

I don't recommend switching any corp/buisness over from ActiveState to Strawberry because they are not even remotely the same thing.

Strawberry is just perl with CPAN and will download whatever you want from CPAN.

Active state is meant to a refined collection of modules where each update to them is reviewed at a code/manual level to ensure you are not installed malicious code. It is meant to be a sandboxed build to limit the code run to only things reviewed/trusted.

While Perl/CPAN does at least seem to need peer review (of a new users work), other languages (especially python and JavaScript) have shown what can happen through blindly trusting online repositories: people can name-squat and a single typo in a module name can have you downloading malicious code. Module owners can go-bad because of political/social/economic reasons and update their own modules maliciously.

What?

ActiveState's "refined collection of modules where each update to them is reviewed at a code/manual level" are simply packaged CPAN modules:

ActiveState maintains repositories of precompiled CPAN packages that can be installed with either the PPM command-line client, or the PPM GUI application.

...and:

ActiveState downloads all new packages from CPAN once a day and tries to build them for each supported platform.

Please stop fear mongering. ActiveState is nothing more than Perl bundled in such a way as to cause lock in.