Looking closely at the code, yes I inadvertently left the $sqld="?" statement
in, but you'll also see that I never made use of it later.....
.Also, I had been connecting through dbiproxy to Postgres on SuSe7.1, I
changed to connecting to PostGres directly and it started working (using the do
statement unmodified, but at others suggestions I have removed the quotes....)
So, it works fine with a direct connect, and claims to work through the proxy,
but never succeeds in reality....in fact it tells me # of rows affected (1)
correctly....(Which with a do statement and the type of sql statements I am
passing is what I should ALWAYS get if it is successful...)
So to sum up my problem...I'd like to connect through the proxy for it's
ability to encrypt the datastream, but evidently the current version of
PlProxyServer.pm and the Current version of DBI (1.16) and the current version
of DBD::Pg don't like eachother. (Or there were errors I missed on the install
of these....) I will be doing a clean install later today on another box to see
if I can get DBIProxy to work there....probably something went wrong when I
upgraded and I missed the error.....
Direct connects to DBD::Pg work great using the same parameters....Direct
connects to an older version of DBI and DBIProxy to an ODBC driver on a WIN2K
box work great, so I think there is something there with my install of the most
current DBIProxy combined with the most Current DBI and most current
DBD::Pg.....
Oh, btb, thanks to your specifically pointing out the code I was able to remove
the deadwood! Thanks...
On Fri, 1 Jun 2001 08:50:08 -0400, [EMAIL PROTECTED] said:
>
>
> I hate to tell you this, but in the code snippet below, you ARE using a
> placeholder for the whole query. The following two lines should probably be
> deleted, as they do nothing helpful:
> $sqld="?";
> $sthd=$dbhd->prepare($sqld);
>
> 'do' statements don't need to be prepared.The $dbhd->do should have its double
> quotes removed, for reasons others have pointed out. Also, 'do' returns the
> number of rows affected, not just pass/fail, so what you have in $success is the
> number of rows that DBI thinks were inserted.
>
> Have you tried connecting to the target database using the same parameters
> you're giving to $dbhd, to verify that you have insert permission to the
> relevant tables?
>
>
>
> "Michael Wray" <[EMAIL PROTECTED]> on
> 05/31/2001 07:57:36 PM
>
> Please respond to "Michael Wray"
> <[EMAIL PROTECTED]>
>
> To: [EMAIL PROTECTED]
> cc: (bcc: Wesley Sheldahl/Lex/Lexmark)
> Subject: In Need of a Miracle...WAS:Re: Pg Connection WOES on DEADLINE!
>
>
> Thanks to all the responses! Rerecording the SQL statements into the
> syncmaster is now working....HOWEVER, Executing them is not....the original
> SQL statements are coming from an MSSQL Servers Sync table (which is where
> @updates comes from...)
>
> Here's what I am doing now:
>
> #Prepare SQL Statement for Updateing SYNCMASTERS LIST And Destination Dbase
>
> $sql="INSERT INTO syncrecords VALUES(?,?)";
> $sth=$dbh->prepare($sql);
> $sqld="?";
> $sthd=$dbhd->prepare($sqld);
> #### UPDATE SYNCMASTER And Destination######
> for my $urow(@updates) {
> # print "INSERT INTO syncrecords VALUES ($urow->[0],$urow->[1])\n";
> $sth->execute($urow->[0],$urow->[1]);
> $dbh->commit;
> $success=$dbhd->do ("$urow->[1]");
> print "\$success=$success\n";
> print "DEBUG:\n CODE: do (\"\$urow->[1]\");\ngenerates:\n$urow->[1]\n BUT
> does ABSOSMURFLY NOTHING!\n";
> $dbhd->commit;
>
> } #End of FOR for updating SYNCMASTER/UPDATES
>
>
>
> $dbhd->commit;
> print"finished\n\n";
> #$sthd->finish();
> $dbhd->disconnect();
> } # end of Inner For Loop
> $sths->finish();
> $dbhs->disconnect();
> }
>
> $dbhs->disconnect();
> $sth->finish();
> $dbh->disconnect();
>
>
>
> The problem now being that while $success equals 1 (or true I presume) no
> errors are reported and no data ends up in the table. In looking at the docs
> for ERROR trapping, I have yet to figure out how to trace what's actually
> happening at this level, just on the CONNECTION level have I figured that out,
> or by watching the Proxy Server in debug mode, which also indicates success on
> these statements.
> I suspect my problem lies in the fact that I'm actually giving the WHOLE SQL
> statement as a variable, which cannot be helped in this case, I cannot think of
> a way around this issue....especially since an UPDATE is a DELETE followed by
> an INSERT and assumptions are that table and fieldnames are all
> lowercase..which they are...so I can do a blind replica....
> I have tried isolating one insert statement and issuing it in a similar
> fashion with the same results, here is the output of program:
>
> $success=1
> DEBUG:
> CODE: do ("$urow->[1]");
> generates:
> insert into synctest1 values(49,'test3',20,'1998-05-20 00:00:00','1')
> BUT does ABSOSMURFLY NOTHING!
> $success=1
> DEBUG:
> CODE: do ("$urow->[1]");
> generates:
> delete from synctest1 where synctestid = 49
> BUT does ABSOSMURFLY NOTHING!
> $success=1
> DEBUG:
> CODE: do ("$urow->[1]");
> generates:
> insert into synctest1 values (49,'test3',20,'1998-05-20 00:00:00','0')
> BUT does ABSOSMURFLY NOTHING!
> $success=1
> DEBUG:
> CODE: do ("$urow->[1]");
> generates:
> delete from synctest1 where synctestid = 49
> BUT does ABSOSMURFLY NOTHING!
> $success=1
> DEBUG:
> CODE: do ("$urow->[1]");
> generates:
> insert into synctest1 values(49,'test3',20,'1998-05-20 00:00:00','1')
> BUT does ABSOSMURFLY NOTHING!
> finished
>
> --
> Michael Wray
> Network Administrator
> FamilyConnect, Inc.
>
>
>
>
>
>
>
>
>
>
--
Michael Wray
Network Administrator
FamilyConnect, Inc.
