Well I got this from your code...
$sqld="?";
$sthd=$dbhd->prepare($sqld);
So evidentally you were doing something wrong that you didn't mean.
Also you might want to read the docs on finish() which in your case you do
not need.
Ilya Sterin
-----Original Message-----
From: [EMAIL PROTECTED]
To: Sterin, Ilya; [EMAIL PROTECTED]
Sent: 05/31/2001 9:55 PM
Subject: Re: RE: In Need of a Miracle...WAS:Re: Pg Connection WOES on
DEADLINE!
Thanks, but no...I have read the PLACE HOLDER DOCS...and I AM NOT USING
A
PLACE HOLDER in the portion that FAILS, the only place that uses a PLACE
HOLDER works just fine (which is inserting the sql statement into
another
database)..(See code below:) I am using a DO statement in a manner,
which
according to the documentation of DO is equivalent to saying:
for $urow (@updates) {
$presql=$urow->[1];
$sql=qq{$presql};
$sth=$dbh->prepare($sql);
sth->execute;
dbh->commit;
}
Which is code I have tried with the exact same results. If, on the other
hand, I do what you are suggesting that I am doing:
$sql=qq{?};
$sth=$dbh->prepare($sql);
sth->execute($urow->[1]);
dbh->commit;
Then the process dies, and does not report success....but rather gives
an
invalid method error.
In theory, if I have $foo="fig", and $bar=$foo, when I access $bar I
should
get "fig", which is what APPEARS to happen at the program level and at
the
proxy level...(i.e. I can see the requests go across the proxy..) but
they
never appear to make it to the database.....So it's more like I just get
$scalar0x000EF (or some other such rot...) which should generate an
error
since sending data by itself generates an error about an improperly
formatted SQL statement.
Whilst I am successfully using the placeholders to insert the actual SQL
statements into another database, that is supposed to just be a
log....actually executing them is what I need to occur...Currently they
are
stored as one string in the database...if an insert occurs, into the
synctable it goes, if a delete occurs, it goes into the table,, if an
UPDATE occurs, a DELETE, then an UPDATE goes into the table.
What's the difference between saying:
$sql=qq{INSERT INTO sometable VALUES('data','data','data');
and:
$presql="INSERT INTO sometable VALUES('data','data','data');";
$sql=qq{$presql};
Which is in effect what I am doing. In theory both $sql statements
should
be seen the same by the prepare portion of the statement....
----- Original Message -----
From: Sterin, Ilya <[EMAIL PROTECTED]>
Sent: Thursday, May 31, 2001 8:19:30 PM
To: Michael Wray <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Subject: RE: In Need of a Miracle...WAS:Re: Pg Connection WOES on
DEADLINE!
> Pleeaassee read the placeholders docs. You can't use a place holder
in
> place of the whole query. Placeholder are used for values, for
example...
>
> "insert into table_1 values (?, 1, ?)"
> "select foo1, foo2 from bar where col1 = ?"
> etc....
>
> Place holders can't even be used to substitute table nor column names.
>
> perldoc DBI and perldoc DBD::Pg are your friends.
>
> Ilya Sterin
>
> -----Original Message-----
> From: Michael Wray [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 31, 2001 7:58 PM
> To: [EMAIL PROTECTED]
> 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.