I want to know what is the easy and simple way to access mysql database.
I'm using Windows. Also I should be able to easily install using Active Perl's perl package manager.
Install DBI and DBD::mysql
For DBD::mysql for ActiveState, have a look at :
http://dev.mysql.com/doc/refman/5.0/en/activestate-perl.html
and
http://code.activestate.com/ppm/DBD-mysql/
As M42 has said, DBI and DBD::mysql should be the basis of any work that needs to talk to a MySQL database.
But I'd go further than that and recommend that you look at DBIx::Class as an easy way to get data from (and into) a database.
Related
I've been searching for a while and I cannot find an easy solution for building an install package on linux for a perl application I've built. My application is a mojolicious application and I am using DBIx::Schema. I need to accomplish the following;
import my DB schema into a database
check for and install any missing perl modules
copy my actual application to a location.
possibly set my application to run as a service.
This is rather trival on windows, but I can't seem to find a clean solution to do this on Linux. Is the easiest approach to just write another perlscript to do the install?
thanks.
Try to use Rex or checkout this SO question Is there a Perl or Lua alternative to Capistrano?.
To deploy your DBIx::Class::Schema you can use $schema->deploy in an install script. It uses SQL::Translator to generate the SQL statements for your RDBMS of choice.
Another possibility to generate the SQL statements in the app build process and store them in text files per supported RDBMS using $schema->deployment_statements.
Many people package their apps like CPAN modules so they can't be installed using the CPAN toolkit apps like cpan, cpanminus or cpanplus.
I need help: is there a way to fetch a file from the remote server using only core modules of perl 5.8.8? File::Fetch became core module only from 5.9.
This comes up all the time. Take a look at the classic yes, even you can use CPAN. If you have the ability to create and run a Perl script, then you also have the ability to put a module in your local directory and use it. The requirement to use only core modules is entirely artificial.
In your case, LWP::Simple's getstore() function will do what you want. While it is technically not core, LWP::Simple is included by default with many Perl distributions. You may well already have it.
Update: so, you want to do this on 1000 servers? No need to manually install the module on each server. Use CPAN programmatically to download and install the module(s) you need (some tweaking will be needed to get CPAN to install it locally rather than in the root module library). Also Leon Timmermans's suggestion of fatpacking the module is another option.
If you really don't want to do it this way, then basically the answer is no: there is no simple way to fetch a remote file via HTTP using neither the appropriate modules, nor a system command (I didn't consider writing your own HTTP client to be a simple method, but that's fine if it works for you).
The only other potential solution I see would be a different approach to your problem, such as:
Using a script in a single location to get the file, then distribute
it to all 1000 servers via FTP.
Or, putting the file on an FTP server, then using a simple Perl
script on each server to fetch it via FTP.
As Dan already said, yes, even you can use CPAN. One approach his link doesn't mention is writing it as a normal CPAN-using distribution, and then fatpack it. Fatpacker combines a script with all its (pure-perl) dependencies, creating a single easy to distribute file.
You could use:
my $wgetoutput = `wget "$myFileToGet"`;
Stuff in backticks (`) will be given to the default shell, so you can call whatever you want (and are allowed) there.
Caveat: $myFileToGet could have stuff like "&& rm -rf *" in it, so dont forget to sanitize!
There are multiple installers for cpan modules available; I know of at least CPAN.pm (comes with perl,) CPANPLUS, and cpanminus.
What is the difference between the three?
What situations call for using one over the other?
Are there other module installers I should know about?
CPAN.pm (cpan) is the original client. It comes with Perl, so you already have it. It has the most features. It has a lot of configuration options to customize the way it works, though virtually everyone accepts the default installation. It integrates easily with local::lib.
cpanminus (cpanm) is an attempt to make a zero-configuration client that automatically does the right thing for most users. It's also designed to run well on systems with limited resources (e.g. a VPS). It doesn't come with Perl, but it's easy to install. It integrates easily with local::lib.
Its biggest limitation is its lack of configuration. If you want to do something unusual, it may not support it.
CPANPLUS (cpanp) is an attempt to make a CPAN API that Perl programs can use, instead of an app that you use from the command line. The cpanp shell is more of a proof-of-concept, and I don't know of any real advantages to using it.
In summary, I'd recommend either cpan or cpanm. If you have trouble configuring cpan, try cpanm. If your situation is unusual, try cpan.
It's impossible answer this question because it is too subjective. :)
From my point of view: cpanm is the simplest way install perl modules. You can install cpanm with:
curl -L http://cpanmin.us | perl - --sudo App::cpanminus
and after it you can install modules with simple:
cpanm Some::Module
You can use cpanm for mirroring (part of) CPAN to you local machine too, so IMHO cpanm is the best for the most common CPAN needs.
Are there other module installers I
should know about?
If you're using a Linux distribution that packages CPAN modules, then it's worth using their package installation program to install modules. For example, Ubuntu/Debian have a huge number of CPAN modules that you can install using 'apt' and Red Hat/Centos/Fedora have a number that you can install using 'yum'.
CPAN is the standard. cpanminus (cpanm) asks fewer questions (best most of the time). I don't know anyone that uses cpanplus.
Since what these modules do is download, compile and install (place files in correct places) they all should do the same task. Some of the difference has to do with the permissions level you have. Perhaps you want to install some things local to your user and some things globally then you need a finer adjustment. Developers may also need to control/interrupt the process for debugging etc.
For daily use, use cpanm, unless you are too lazy to install it, then CPAN is fine.
cpanm uses much less memory. This makes it a better choice for environments where RAM is limited, such as shared hosting servers, where regular cpan might die before completing installation task, due to attempting to use more than available memory.
According to cpanm's (1.7044) documentation "When running, it requires only 10MB of RAM"
I have GNU R installed (the S-like statistics package; version 2.8.1) and PostgreSQL (8.4.1), but I cannot connect GNU R to my RDBMS.
When I first did this (years ago - code lost) DBI for R didn't exist. Now it does. I am also confused as to which R package to use. A quick search returns:
RPostgreSQL seems to be the most up-to-date
RPgSQL Looks abandoned. I wish they would put a date on their webpage. ;-(
My Linux distribution doesn't package R packages (irony) but I am comfortable running R CMD INSTALL package.tar.gz.
I installed RPostgreSQL: a lot of documentation says to call dbConnect but I get the following error message: Error: object "dbConnect" not found.
Just for completeness, you have two more options
RODBC which is very mature and feature-complete but doesn't correspond to the DBI framework as the PostgreSQL, MySQL, SQLite, Oracle, ... interfaces do. You also need to fiddle with ODBC setup files which can be tricky. But ODBC may be useful for other data access uses too.
RdbiPgSQL from the BioConductor project which is also mature but uses yet another protocol that was to compete with DBI and never took of. This PostgreSQL package is featureful though.
But as a RPostgreSQL maintainer/co-author I am glad you found this one. As the other poster suggested, try library(RPostgreSQL) before issueing commands. If you encounter other problems, feel free to email me off-SO with a bug report.
Edit: There is another option of embedding R inside PostgreSQL using Joe Conway's PL/R.
Maybe you need to run require(RPostgreSQL) before you can use dbConnect?
My guess is you need to install the DBI package (most database packages depend on it).
If you use install.packages('RPpostgreSQL',dep=TRUE) from within R it should take care of any dependency issues.
RODBC works great for me. You just have to set up a data source name (DSN) for the database you want to connect to. I find this nice because then the specific connection info does not have to be stored in R, and it may vary for your collaborators.
Also, yes, it sounds like you haven't loaded the RPostgresSQL package.
I can't seem to find a good script or anything to use for installing Firebird (the InterBase-decendent RDBMS) using InstallShield. There is a way to silently install it using the firebird install executable, but I don't know enough about InstallShieldscripts to be able to do it! If anyone knows any information on
a) how to execute an exe from InstallShield
b) how to install firebord using InstallShield
I would be very appreciative! Thanks a lot, Matt
You should probably reword your question to get answers about how to execute an external program using command line parameters in an InstallShield script. Maybe the documentation would have enough info on that already.
Regarding the installation of Firebird, please have a look at this document which comes with the Firebird installation and shows all available switches for the Firebird setup executable. If you don't want the user to see that your program is installing Firebird you should probably use the /SP-, the /VERYSILENT and /SUPPRESSMSGBOXES switches. Other switches worth looking into are /NOICONS to suppress the creation of a program group in the start menu, and /COMPONENTS=... to install only what is absolutely necessary for your program to function.
Please note that installing Firebird is only a part of what you should do. For clear separation from other programs using Firebird you should create a new Firebird user account with password, and it's always a good idea to add an alias for your database to the aliases.conf file.