newbie oraperl Q - raw field access 
Author Message
 newbie oraperl Q - raw field access


> That's depressing.  The stumbling block seems to be:
>     ORA-01460: unimplemented or unreasonable conversion requested
> Does anyone have more details on what this _really_ means?

> Long Raw data cannot be converted to Oracle char type data, and I
> assume that OraPerl tries to fetch all Oracle data as char for easy
> loading of perl scalars.

> BTW, it was pointed out to me that LONG data is OK, as it can be
> converted to char.  Only LONG RAW is impossible.

> Does anybody have an Oracle ProC subroutine that could fetch LONG RAW
> data from a Table and push the data into a file that the perl script could
> read in and deal with?  This way instead of using orafetch to get the
> LONG RAW data from the table, you can just exec the C code and pass it
> the name of the file you want to end up working with.

> I've asked my Oracle experts and they think it would be the only way to
> do it. well.. either ProC or (ick!) Visual Basic.

[Sorry if I got any attributions wrong while untangling all that]

I haven't been able to contribute to it, but I've been following the
discussion about fetching RAW and LONGRAW data using Oraperl. Putting
together the various comments and some tests that the original poster
did for me, I think that this is an unreasonable limitation by Oracle,
but also a bug in Oraperl.

As Roy Johnson pointed out, Oraperl fetches all data types by asking
Oracle to convert them into character strings. This makes the Oraperl
code simpler because it doesn't have to worry about allocating several
different buffers for the different datatypes. It also makes it
possible to correctly handle Oracle's NUMBER type; C has no native
datatype capable of handling 38 digits of precision, but by using
strings, Oraperl can return them and Perl can handle them (using the
Bignum package).

Oracle, however, refuses to convert RAW data into a string. I presume
that the rationale is as follows:

        1)  in C, strings are terminated by a NUL character
        2)  RAW data may contain any number of NULs, with useful
            information after them
        3)  therefore, we do not convert RAW data to a string

I consider this limitation to be unreasonable because assertion (1)
is not strictly true. The functions which handle strings do make this
assumption, but C can happily deal with char arrays containing anything,
including multiple NULs.

However, I also consider it to be a serious bug in Oraperl, because it
ought to work round the limitation!

Unfortunately, I am not in a position to fix it myself, as I no longer
have access to Oracle, or even to the documentation. I don't think that
it is a difficult problem to fix. Is there someone who would be willing
to fix the problem and send off a patch to comp.sources.misc? I would
be happy to offer any help I can (including my analysis of what needs to
be changed and how).

So, any volunteers? Obviously, you need to be conversant with C and
Oraperl. When you send me mail, please tell me what the parameter to
odefin() is to get it to return RAW data as a character array.



Disclaimer: This posting represents the poster's views, not those of Auspex

Sat, 15 Mar 1997 21:54:33 GMT  
 [ 1 post ] 

 Relevant Pages 

1. newbie oraperl Q - raw field access

2. newbie oraperl Q - raw field access

3. Using oraperl to retrieve a long raw database field

4. : novice Qs: minimal input loops, field specifiers

5. Oraperl and long raw ???

6. Long Raw in Oraperl

7. Long Raw datatype with Oraperl

8. Long Raw, BLOBS, OraPERL

9. Oraperl, Long Raw, and BLOBS??

10. ORAPERL and LONG RAW datatypes

11. Newbie: 2 More Substitution Regex Qs

12. Help: accessing text of raw http request


Powered by phpBB® Forum Software