Re: regarding DBI module not working windows 2010
Op zo 15 januari 2012 om 23:57:38 (+0530) schreef sridhar.dachepe...@gmail.com (Sridhar Dachepelly): Hello, I am trying to use DBI module in Windows 2010 server, i have installed perl 5,14 version (64-BIT). DBI module is not working and giving errors. Could you please look into the below errors and suggest what we can do for the same. [...] Perl lib version (v5.8.6) doesn't match executable version (v5.14.2) at C:/Program Files/IBM/RationalSDLC/common/lib/perl5/5.8.6/MSWin32-x86-mult i-thread/Config.pm line 32. [...] Others have already explained what is wrong -- your computer has multiple versions of Perl (which is OK), and one version is calling libraries of another version (which is not OK). Make sure the Perl you are using is using the modules compatible with it, and you will be fine. I will try to explain how this error can come to happen. Usually, when you install Perl, all the modules that get installed with it are installed correctly to be used by it. When you install new modules after the fact, they too get installed correctly respective to the Perl you used to install them. So, imagine I have (unix examples ahead, but the logic would apply for Windows as well) /usr/bin/perl5.8.6 (aka p1) and /opt/local/bin/perl5.14.1 (aka p2)... if I install modules using `p1 -MCPAN -eshell` then they will get installed under /usr/lib/perl whatever, and if I install modules using `p2 -MCPAN -eshell` they will be installed correctly for p2 under /opt/local/lib/perl etc. Now, the modules that are used depend on the perl that is used. So, if your program explicitly calls `#!/usr/bin/perl` then it will use modules under /usr/lib/perl and if your program calls `#!/opt/local/bin/perl` it will use the modules under /opt/local/lib. The problem happens if either a different perl than what you expect is hard-coded in some program, or you are making some implicit calls, such as those by `#!/usr/bin/env perl`. For example, the latter is dependent on what it finds using /usr/bin/env, which would be different when run in a shell than when run in some other context. Moral of the story -- there is nothing wrong with having multiple perls... in fact, feel free to use something like perlbrew to install and control your own custom perl or many of them. Just make sure the perl you are using is using the modules that match it. -- Puneet Kishor
regarding DBI module not working windows 2010
Hello, I am trying to use DBI module in Windows 2010 server, i have installed perl 5,14 version (64-BIT). DBI module is not working and giving errors. Could you please look into the below errors and suggest what we can do for the same. C:\intranet\integration\cardsperl label2.pl Use of :unique is deprecated at C:/Program Files/IBM/RationalSDLC/common/lib/perl5/5.8.6/MSWin32-x86-multi-thread/Config.pm line 39. Use of :unique is deprecated at C:/Program Files/IBM/RationalSDLC/common/lib/perl5/5.8.6/MSWin32-x86-multi-thread/Config.pm line 1050. Perl lib version (v5.8.6) doesn't match executable version (v5.14.2) at C:/Program Files/IBM/RationalSDLC/common/lib/perl5/5.8.6/MSWin32-x86-mult i-thread/Config.pm line 32. Compilation failed in require at C:/Program Files/IBM/RationalSDLC/common/lib/perl5/5.8.6/MSWin32-x86-multi-thread/DynaLoader.pm line 25. BEGIN failed--compilation aborted at C:/Program Files/IBM/RationalSDLC/common/lib/perl5/5.8.6/MSWin32-x86-multi-thread/DynaLoader.pm line 25. Compilation failed in require at C:/Program Files/IBM/RationalSDLC/common/lib/perl5/5.8.6/DBI.pm line 160. BEGIN failed--compilation aborted at C:/Program Files/IBM/RationalSDLC/common/lib/perl5/5.8.6/DBI.pm line 160. Compilation failed in require at label2.pl line 1. BEGIN failed--compilation aborted at label2.pl line 1. Thanks, Shridhar.
Re: (Fwd) Question regarding DBI status
The design is stable until the business model changes. Which is the case with RD projects as they are constantly changing. The applications we are writing are things that do not exist in any capacity in the market. Which makes stable a relative term when comparing it to a banking or warehousing situation. Also, keep in mind that the applications we are writing are quite large with a large user base and we have a very small team (over half are junior developers). In an RD capacity, faster turn around is key, so having the ability to lower maintenance code changes is vital. Some possible maintenance issues: - changing all the sql to get the new column. - having different names for your aliases from query to query become confusing. Also, I'm not sure what you mean by a hash array. I am guessing you are getting a hash or hash reference. I too am using the fetchrow_hashref, however it drops the table prefix on the return column names, which in turn clobbers column names that are the same across tables. Thus the reason for this thread. I was really just looking for any future planning done on the DBI side of things to aid with getting back full information. Either a flag to pass into the function call, or new functions which return the table names prefixed as you would see when running the SQL directly from a console. It seems that other languages, such as Java, do not seem to have is issue, both ways of retrieval are possible. If the fetchrow_hashref were changed to house both types of keys (those without table prefixes and those with), in the way Java and other languages work, then this would be a mute point. -Link On Tue, Aug 11, 2009 at 1:25 AM, Jared Stilljkst...@verizon.net wrote: On Thu, 2009-08-06 at 10:23 -0400, Link McGaughey wrote: ...aliasing each of the column names, but this becomes a maintenance issue when you have alter the selected columns every time there is a change to the table. Personally, I would work on stabilizing the design. Tables frequently being changed would indicate to me that whoever is designing the tables is not yet sure what to do with them. I'm curious as to just what the maintenance issues are? Normally I would expect to see all SQL statements packaged together somehow, and each SQL statement appears only once. Personally, I use a hash array, version them according to database version. This simplifies changes a bit. SELECT * FROM table1 t1 JOIN table2 t2 ON (t1.column_id = t2.column_id) WHERE ... In general, using 'select *' is not a good practice. One good reason is that it is a resource hog. It takes a fair amount more resources to do 'select *' rather than just selecting just the needed columns, especially when a small percentage of the columns are actually used. Yes, I know you didn't ask, but thought you would like to know. It's not too hard to test this yourself. I've done so on Oracle, but not on MySQL. And no, I don't care if 'select *' is easier to code. :)
Re: (Fwd) Question regarding DBI status
On Tue, Aug 11, 2009 at 01:21:53PM -0400, Link McGaughey wrote: [...] I too am using the fetchrow_hashref, however it drops the table prefix on the return column names, which in turn clobbers column names that are the same across tables. Thus the reason for this thread. I was really just looking for any future planning done on the DBI side of things to aid with getting back full information. Either a flag to pass into the function call, or new functions which return the table names prefixed as you would see when running the SQL directly from a console. It seems that other languages, such as Java, do not seem to have is issue, both ways of retrieval are possible. If the fetchrow_hashref were changed to house both types of keys (those without table prefixes and those with), in the way Java and other languages work, then this would be a mute point. I know that a few _databases_ can do that, but most don't. For those that don't, the client API (in Java or any other language) simply can't provide the information. For those that do the corresponding DBI driver could provide a driver-private attribute to enable table name/aliases in the hash keys. Tim.
Re: (Fwd) Question regarding DBI status
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I was really just looking for any future planning done on the DBI side of things to aid with getting back full information. Either a flag to pass into the function call, or new functions which return the table names prefixed as you would see when running the SQL directly from a console. Where are you seeing such a thing? I think this problem is out of the reach of a DBI solution. Databases return whatever you've specified in the SELECT list: if using '*', it returns the column names by default, but is under no compunction to return the table name as well. Thus, even if you manage to convince us to add a flag to the DBI API, there is no way for some (most?) drivers to extract that information anyway. Consider: postgres=# create table f1(a int); CREATE TABLE postgres=# create table f2(a int); CREATE TABLE postgres=# insert into f1 values (1); INSERT 0 1 postgres=# insert into f2 values (2); INSERT 0 1 postgres=# select *, f1.*, f2.*, 3 as a from f1, f2; a | a | a | a | a - ---+---+---+---+--- 1 | 2 | 1 | 2 | 3 (1 row) mysql create table f1(a int); Query OK, 0 rows affected (0.00 sec) mysql create table f2(a int); Query OK, 0 rows affected (0.00 sec) mysql insert into f1 values (1); Query OK, 1 row affected (0.00 sec) mysql insert into f2 values (2); Query OK, 1 row affected (0.00 sec) mysql select *,f1.*, f2.*, 3 as a from f1, f2; +--+--+--+--+---+ | a| a| a| a| a | +--+--+--+--+---+ |1 |2 |1 |2 | 3 | +--+--+--+--+---+ 1 row in set (0.00 sec) There are plenty of other non-DBI solutions available to you, the primary one being having your app not rely on such a solution. Another is creating specific aliases if you need things returned with specific names, like so: postgres=# select f1.a as f1.a, f2.a as f2.a, 3 as a from f1, f2; f1.a | f2.a | a - --+--+--- 1 |2 | 3 (1 row) - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200908120608 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkqClmcACgkQvJuQZxSWSsh/BgCg2tz/JIY/tykZF2i3ORJjtirw 0OAAnRJ/agRNVbU9AuMILgEChIB9PnZH =ZXrc -END PGP SIGNATURE-
Re: (Fwd) Question regarding DBI status
On Thu, 2009-08-06 at 10:23 -0400, Link McGaughey wrote: ...aliasing each of the column names, but this becomes a maintenance issue when you have alter the selected columns every time there is a change to the table. Personally, I would work on stabilizing the design. Tables frequently being changed would indicate to me that whoever is designing the tables is not yet sure what to do with them. I'm curious as to just what the maintenance issues are? Normally I would expect to see all SQL statements packaged together somehow, and each SQL statement appears only once. Personally, I use a hash array, version them according to database version. This simplifies changes a bit. SELECT * FROM table1 t1 JOIN table2 t2 ON (t1.column_id = t2.column_id) WHERE ... In general, using 'select *' is not a good practice. One good reason is that it is a resource hog. It takes a fair amount more resources to do 'select *' rather than just selecting just the needed columns, especially when a small percentage of the columns are actually used. Yes, I know you didn't ask, but thought you would like to know. It's not too hard to test this yourself. I've done so on Oracle, but not on MySQL. And no, I don't care if 'select *' is easier to code. :)
(Fwd) Question regarding DBI status
- Forwarded message from Link McGaughey link.mcgaug...@gmail.com - Date: Wed, 5 Aug 2009 18:41:56 -0400 Subject: Question regarding DBI status From: Link McGaughey link.mcgaug...@gmail.com To: tim.bu...@pobox.com Tim, I found your information from CPAN, and had a question regarding the status of active development for DBI more specifically 'fetchrow_hashref'. The issue that I am having is based around 'JOIN' statements and table with same named columns. I have found several work arounds to my problem, but didn't know if there was a version of DBI that left the table name prefixed to the column name. (ie table.column). Any information would be great. Thanks, -Link - End forwarded message -
Re: (Fwd) Question regarding DBI status
Not to speak for Tim on this but here is my 2cents worth, Your case here is poor SQL and or table design which you are trying to account for with DBI. If you intend to use the cursor/recordset column 'headers' as unique identifiers then you should set them up as such. ie Select test.id as user_name, new.id as user_id, test.name as old_name, new.number as Number from test, new where test.id=new.id Never assume your third party tool will will fix this sort of problem for you. cheers Tim Bunce wrote: - Forwarded message from Link McGaughey link.mcgaug...@gmail.com - Date: Wed, 5 Aug 2009 18:41:56 -0400 Subject: Question regarding DBI status From: Link McGaughey link.mcgaug...@gmail.com To: tim.bu...@pobox.com Tim, I found your information from CPAN, and had a question regarding the status of active development for DBI more specifically 'fetchrow_hashref'. The issue that I am having is based around 'JOIN' statements and table with same named columns. I have found several work arounds to my problem, but didn't know if there was a version of DBI that left the table name prefixed to the column name. (ie table.column). Any information would be great. Thanks, -Link - End forwarded message -
RE: (Fwd) Question regarding DBI status
unique identification of a column with tablename.column is sop (at least in the oracle world) i assume Mr McGaughey is learning and thus the reason for our helping instead of engaging in vilification activity speaking of learning where is/are column-name 'headers' defined ? Martin Gainty __ Note de déni et de confidentialité Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Thu, 6 Aug 2009 08:26:07 -0400 From: sco...@pythian.com To: tim.bu...@pobox.com CC: dbi-users@perl.org; link.mcgaug...@gmail.com Subject: Re: (Fwd) Question regarding DBI status Not to speak for Tim on this but here is my 2cents worth, Your case here is poor SQL and or table design which you are trying to account for with DBI. If you intend to use the cursor/recordset column 'headers' as unique identifiers then you should set them up as such. ie Select test.id as user_name, new.id as user_id, test.name as old_name, new.number as Number from test, new where test.id=new.id Never assume your third party tool will will fix this sort of problem for you. cheers Tim Bunce wrote: - Forwarded message from Link McGaughey link.mcgaug...@gmail.com - Date: Wed, 5 Aug 2009 18:41:56 -0400 Subject: Question regarding DBI status From: Link McGaughey link.mcgaug...@gmail.com To: tim.bu...@pobox.com Tim, I found your information from CPAN, and had a question regarding the status of active development for DBI more specifically 'fetchrow_hashref'. The issue that I am having is based around 'JOIN' statements and table with same named columns. I have found several work arounds to my problem, but didn't know if there was a version of DBI that left the table name prefixed to the column name. (ie table.column). Any information would be great. Thanks, -Link - End forwarded message - _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=PID23384::T:WLMTAGL:ON:WL:en-US:NF_BR_sync:082009
Regarding DBI
hi i would like to know the detailed architecture and design of dbi. i would like to know how its been written and how it interacts with the drivers etc. i would like to know whats going on internally... any pointers to this would be appreciated. thanks in advance. Regards, Prashanth.
Re: Regarding DBI
On 06/19/2005 10:24 PM, prashanth said: i would like to know the detailed architecture and design of dbi. i would like to know how its been written and how it interacts with the drivers etc. i would like to know whats going on internally... any pointers to this would be appreciated. thanks in advance. The full source code is part of the distribution archive. The design philosophy is described in the documentation. http://search.cpan.org/~timb/DBI/ http://search.cpan.org/~timb/DBI/DBI.pm#Architecture_of_a_DBI_Application -- Mac :}) ** I usually forward private questions to the appropriate mail list. ** Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
regarding DBI
hi i want to write an interface (a very simple one) similar to the DBI. could any one give me some suggestions or give relevent pointers regarding the same. i couldnt get any pointers on the internal architecture or philosophy of the DBI...thank you. Regards, Prashanth
Re: regarding DBI
prashanth wrote: hi i want to write an interface (a very simple one) similar to the DBI. could any one give me some suggestions or give relevent pointers regarding the same. i couldnt get any pointers on the internal architecture or philosophy of the DBI...thank you. You want us to do your homework?
Re: regarding DBI
On 6/20/05, Clive Eisen [EMAIL PROTECTED] wrote: You want us to do your homework? For collective learning if we are asked to do so ... We must be ready Best Vasundhar prashanth wrote: i want to write an interface (a very simple one) similar to the DBI. could any one give me some suggestions or give relevent pointers -- vasundhar 9880025682 Institute of Bioinformatics and Applied Biotechnology G-05, Tech Park Mall, International Technology Park, Whitefield Road, Bangalore 560 066, India. Tel: +91 (80) 2841-0029, 2841-2769 Fax: +91 (80) 2841-276
Re: regarding DBI
On 06/20/2005 04:24 AM, vasundhar said: On 6/20/05, Clive Eisen [EMAIL PROTECTED] wrote: You want us to do your homework? For collective learning if we are asked to do so ... We must be ready Then read the fine manual with the URL I gave you before: http://search.cpan.org/~timb/DBI/DBI.pm -- Mac :}) ** I usually forward private questions to the appropriate mail list. ** Ask Smarter: http://www.catb.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
Re: Regarding DBI
On Mon, Jun 20, 2005 at 01:21:34AM -0700, Michael A Chase wrote: On 06/19/2005 10:24 PM, prashanth said: i would like to know the detailed architecture and design of dbi. i would like to know how its been written and how it interacts with the drivers etc. i would like to know whats going on internally... any pointers to this would be appreciated. thanks in advance. The full source code is part of the distribution archive. The design philosophy is described in the documentation. http://search.cpan.org/~timb/DBI/ http://search.cpan.org/~timb/DBI/DBI.pm#Architecture_of_a_DBI_Application Also http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/index.htm Tim.
Question regarding DBI and DBD::Oracle
Hello, Is there any timeframe in which scrolling cursors will be supported within DBI or DBD::Oracle (not sure where this support would be handled). Thanks, Steve -- = Steve Mayer Oracle Corporation Senior Member of Technical Staff1211 SW 5th Ave. Portland Development Center Suite 900 [EMAIL PROTECTED]Portland, OR 97204 Phone: 503-525-3127 =
Re: Question regarding DBI and DBD::Oracle
On Tue, Dec 18, 2001 at 12:16:30PM -0800, Steve Mayer wrote: Hello, Is there any timeframe in which scrolling cursors will be supported within DBI or DBD::Oracle (not sure where this support would be handled). Not anytime soon unless someone sponsors the development. Someone, perhaps, like a large company shipping DBI and DBD::Oracle with it's products ;-) Tim. p.s. But scrolling cursors are in my plans. Thanks, Steve -- = Steve Mayer Oracle Corporation Senior Member of Technical Staff 1211 SW 5th Ave. Portland Development Center Suite 900 [EMAIL PROTECTED] Portland, OR 97204 Phone: 503-525-3127 =
