Thank you for your responses. I'm not really learning, I've been doing this stuff for several years. However, I've finally decided to post the question as it seems that this isn't going to resolve itself. I can do as you suggested by 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. I seems to me that the better solution would be to get a list of named parameter back from your query search with out having to change the naming or hard code values. It also seems that the alternative is to rely on the array values, which again is error prone should the query order change.
As stated I have found hacks that will allow me to prepend the table name and put the values in the hash ref that is returned, it just seems to me that this feature (widely used and needed for all types of databases) should be available via the API itself. SELECT * FROM table1 t1 JOIN table2 t2 ON (t1.column_id = t2.column_id) WHERE ... Martin, I have found a way to add the table prefix, but it is a work around hack and this is for MySQL only (luckily I'm using MySQL in this instance). http://www.perlmonks.org/?node_id=518184 On Thu, Aug 6, 2009 at 8:56 AM, Martin Gainty<mgai...@hotmail.com> wrote: > 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. Check it out.
