Hi David, Not being dubious, really am a newbie ... as far as Perl+DBI is concern. I can look at Perl codes on the average but not if the whiz programmers start using a lot of shortcuts etc.... My daytime job is as an Oracle DBA. Most of the scripting I do is mainly UNIX scripting and very limited Perl stuff.
Believe it or not, the customer we support is very strict and does not want stuff getting installed which is why my initial approach to the problem is to check whether I can use the DBI that is supposesly installed already with Oracle Enterprise Manager (OEM) but that does not work either. Using the non-DBI approach is purely so that I can connect as "/as sysdba". I know that using DBI that I can also do "/as sysdba" without supplying a password, someone from the group had confirmed that but of course, it goes back to the original scenario where I have to install the DBI module. Anyway, I will try to look at installing Perl for Windows on a client PC instead and then install DBI and Oracle Client on it. The thing with this approach is because the password is exposed, which is way they are okay with the initial approach of running the scripts on the servers instead and using "/as sysdba" but obviously, Micro$oft doesn't work that well with the *nix approach. I've check on some DBI tutorial and it looks like a very steep learning curve ... anyway, I'll try my best to learn it best I could ... Got any links to recommend? Thanks to everyone who had responded to this post ... On Tue, Apr 20, 2010 at 1:56 AM, David Nicol <davidni...@gmail.com> wrote: > Someone calling themselves newbie01.perl is really kind of dubious, > couldn't you have made up a more fun nomme de guerre, like "Olyve > Crudite"? I'm going to pretend you did. > > Olyve -- > > >> print << `EOL`; > >> sqlplus -S "/as sysdba" <<SQLEND > > the backslashes around the heredoc termination marker indicate that > what is printed is going to be the output of an external script. That > external script also includes a heredoc. > > One way to revise this so it relies on shell features common to the > shells on more platforms might be > > open SQLPLUS, '|sqlplus -S "/as sysdba" > sqlplusoutput.tmp' or die $!; > print SQLPLUS <<SQLEND; > ... > SQLEND > close SQLPLUS; > open TMP, '<sqlplusoutput.tmp' or die $!; > print (<TMP>); close TMP; unlink 'sqlplusoutput.tmp'; > > > Shlomi wrote: > > > The <<SQLEND here document is parsed and executed by the UNIX shell, and > it is > > not supported on the Win32 excuse for a shell called CMD.EXE. You can try > > doing it using cygwin or something if that is an option or alternatively > > writing these command to a file first and then loading it using > > "< input-file.txt" which is more portable. > > That of course would work too. There are many ways to do this. And if > there are a lot of these things, running them all with cygwin might be > less painful than editing each of them. But if you're going to do > that, why not simply install Linux, perhaps in a VM? Please don't > answer, that's a rhetorical question. > > > dln > > > -- > I like to think that when I ramble on, I'm speaking for others who > share my opinions or point of view but who aren't as expressive. >
