RE: Getting spatial data?
-Original Message- From: Todd Chisholm Sent: Thursday, June 22, 2006 1:54 PM Subject: Getting spatial data? my $query = select geometry from processed_product where id=15601; my $sth = $connect-prepare($query); $sth-execute(); [snip] DBD::Oracle::db prepare failed: ERROR OCIDefineObject call needed but not implemented yet [for Statement select geometry from processed_product where id=15601] at /home/corp14/tchishol/oracleTst.pl line 11. You can't use native PL/SQL object types directly in Perl. You'll have to select just the properties you need in the select clause, like: select geometry.get_dims() from processed_product where id=15601 Can't call method execute on an undefined value at ...oracleTst.pl line 12. Just nit picking here, but don't forget || die $connect-errstr after your prepare statement. Philip
Re: Getting spatial data?
Tricky one. The sdo_geometry is a very Oracle specific binary field as DBI and DBD::Oracle basically default of strings so the program dies. You may want to define the field as an ora_type = ORA_CLOB or ORA_BLOB and get it that way. If may work. I might have write a patch for it and treat it as a BLOB. (Tomorrow is my DBD::Oracle day so I may get to look at it) cheers John Scoles - Original Message - From: Todd Chisholm [EMAIL PROTECTED] To: dbi-users@perl.org Sent: Thursday, June 22, 2006 1:54 PM Subject: Getting spatial data? Hi all, I'm trying to get some sdo data, but running into trouble. The program snippet: my $connect = DBI-connect( dbi:Oracle:, '', '', ) || die No connect; #my $query = select update_date from processed_product where id=15601; my $query = select geometry from processed_product where id=15601; my $sth = $connect-prepare($query); $sth-execute(); The result: DBD::Oracle::db prepare failed: ERROR OCIDefineObject call needed but not implemented yet [for Statement select geometry from processed_product where id=15601] at /home/corp14/tchishol/oracleTst.pl line 11. Can't call method execute on an undefined value at ...oracleTst.pl line 12. The 'geometry' type is sdo_geometry. Anyone had luck working with this type of data? Thanks, Todd
Re: Getting spatial data?
Great, thanks for your help guys. Right now, I'm getting it out with getvertices. Didn't know how that worked. I may try the BLOB as well, to streamline things, since I just need a dump of it. Philip, I added the die command, thanks (usually they are there...really!) Todd On 6/22/06, John Scoles [EMAIL PROTECTED] wrote: Tricky one. The sdo_geometry is a very Oracle specific binary field as DBI and DBD::Oracle basically default of strings so the program dies. You may want to define the field as an ora_type = ORA_CLOB or ORA_BLOB and get it that way. If may work. I might have write a patch for it and treat it as a BLOB. (Tomorrow is my DBD::Oracle day so I may get to look at it) cheers John Scoles - Original Message - From: Todd Chisholm [EMAIL PROTECTED] To: dbi-users@perl.org Sent: Thursday, June 22, 2006 1:54 PM Subject: Getting spatial data? Hi all, I'm trying to get some sdo data, but running into trouble. The program snippet: my $connect = DBI-connect( dbi:Oracle:, '', '', ) || die No connect; #my $query = select update_date from processed_product where id=15601; my $query = select geometry from processed_product where id=15601; my $sth = $connect-prepare($query); $sth-execute(); The result: DBD::Oracle::db prepare failed: ERROR OCIDefineObject call needed but not implemented yet [for Statement select geometry from processed_product where id=15601] at /home/corp14/tchishol/oracleTst.pl line 11. Can't call method execute on an undefined value at ...oracleTst.pl line 12. The 'geometry' type is sdo_geometry. Anyone had luck working with this type of data? Thanks, Todd
Always Die (was: RE: Getting spatial data?)
Just to expand on that piece of the discussion, there are cases where I
don't use 'die' on DBI statements at all.
For instance, I may have a system script (not for end users) whose
purpose is to do some database update operations and either succeed or
fail. If it succeeds then it does the whole job correctly, if it fails
then it makes no changes and returns an error code. The specific errors
in the failure case will show up in the log, and everything will be
rolled back.
For that purpose I will open the DBI connection with these options
(amongst others): { PrintError = 1, RaiseError = 1, AutoCommit = 0
}.
As Larry says, there is more than one way to do it, and for some
purposes you can use this as a consistent and clean error handling
policy without the explicit 'die' on every statement.
-Will
-Original Message-
From: Garrett, Philip (MAN-Corporate)
[mailto:[EMAIL PROTECTED]
Sent: Thursday 22 June 2006 14:08
To: dbi-users@perl.org
Subject: RE: Getting spatial data?
Just nit picking here, but don't forget || die $connect-errstr
after your prepare statement.
- - - - - Appended by Scientific Atlanta, a Cisco company - - - - -
This e-mail and any attachments may contain information which is confidential,
proprietary, privileged or otherwise protected by law. The information is
solely intended for the named addressee (or a person responsible for delivering
it to the addressee). If you are not the intended recipient of this message,
you are not authorized to read, print, retain, copy or disseminate this message
or any part of it. If you have received this e-mail in error, please notify the
sender immediately by return e-mail and delete it from your computer.
RE: Always Die (was: RE: Getting spatial data?)
Yeah, you're right. T definitely IMTOWTDI. Using RaiseError is a valid
choice, as is checking each call for errors. However, you do need one or the
other. Calling a method on a undefined variable is rarely one of TWTDI.
From: Rutherdale, Will [mailto:[EMAIL PROTECTED]
Sent: Thu 6/22/2006 6:22 PM
To: dbi-users@perl.org
Subject: Always Die (was: RE: Getting spatial data?)
Just to expand on that piece of the discussion, there are cases where I
don't use 'die' on DBI statements at all.
For instance, I may have a system script (not for end users) whose
purpose is to do some database update operations and either succeed or
fail. If it succeeds then it does the whole job correctly, if it fails
then it makes no changes and returns an error code. The specific errors
in the failure case will show up in the log, and everything will be
rolled back.
For that purpose I will open the DBI connection with these options
(amongst others): { PrintError = 1, RaiseError = 1, AutoCommit = 0
}.
As Larry says, there is more than one way to do it, and for some
purposes you can use this as a consistent and clean error handling
policy without the explicit 'die' on every statement.
-Will
-Original Message-
From: Garrett, Philip (MAN-Corporate)
[mailto:[EMAIL PROTECTED]
Sent: Thursday 22 June 2006 14:08
To: dbi-users@perl.org
Subject: RE: Getting spatial data?
Just nit picking here, but don't forget || die $connect-errstr
after your prepare statement.
- - - - - Appended by Scientific Atlanta, a Cisco company - - - - -
This e-mail and any attachments may contain information which is confidential,
proprietary, privileged or otherwise protected by law. The information is
solely intended for the named addressee (or a person responsible for delivering
it to the addressee). If you are not the intended recipient of this message,
you are not authorized to read, print, retain, copy or disseminate this message
or any part of it. If you have received this e-mail in error, please notify the
sender immediately by return e-mail and delete it from your computer.
