Juergen Sauer wrote:
I prefer on application site to store cahr/varchar contents mime64 encoded,
due problems with non printable/control characters in such strings:
- - often sql-statements does not work in repmcli, if such a column contains \' or \" or \r or \n
- - dataextract and dataload does not work any more, if a \n \r is in the string
- - somewhhat script language php, perl, python, java quits on such strings also

As work arounf I use mime64 encoded strings to be stored in Sap-DB, this has the
benefits:
- - works, in any environments, due the critical chars are not disturbing anymore
this are the contras:
- - "order by" ist not usable
- - "index" is not mor sufficient

So it would be fine to have both combined.
If the SapDB kernel would know about mime64 it could be possible:
create table mime_example
(
id int default serial,
name char(40) mime64,
memo char(4096) mime64
primary key (id, name)
)
//

and this could work also:

select * from mime_example order by name
//
Wouldn't it be easier to teach repmcli/loadercli about proper quoting rules? As for the scripting languages, at least when working with parameters (WHERE col = ?), they should be able to handle it.

I don't think it would be even possible in the current implementation for the same reasons we cannot implement collations: keys and index entries are not compared as a list of fields but as one large byte string, so a type specific comparison routine is currently out.

Daniel Dittmar

--
Daniel Dittmar
SAP DB, SAP Labs Berlin
[EMAIL PROTECTED]
http://www.sapdb.org


_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general

Reply via email to