Writing bzcompressed data into SQL-DB?

Hi,

when compressing strings with bzcompress, I have the problem that the
result apparently often contains 'letters' that mess up sql statements.

Of course I can urlencode the string, but that wont keep it as small.
What would be the best way to send a bzcompressed string to a SQL
statement? is it possible at all without urlencode?

thanks

Oliver

On Sat, 21 Aug 2004 08:46:44 GMT, Oliver Spiesshofer <oliver@email.com> wrote:

>when compressing strings with bzcompress, I have the problem that the
>result apparently often contains 'letters' that mess up sql statements.
>
>Of course I can urlencode the string, but that wont keep it as small.
>What would be the best way to send a bzcompressed string to a SQL
>statement? is it possible at all without urlencode?

The best way depends on which database you are using. Which one is it?

--
Andy Hassall / <andy@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

Oliver Spiesshofer wrote:

> Hi,
>
> when compressing strings with bzcompress, I have the problem that the
> result apparently often contains 'letters' that mess up sql statements.
>
> Of course I can urlencode the string, but that wont keep it as small.
> What would be the best way to send a bzcompressed string to a SQL
> statement? is it possible at all without urlencode?
>
> thanks
>
> Oliver
>

Unless it is a password where the data is short enough or the data is NEVER used
in a select statement (using LIKE '%some text%' I would advise to NOT compress
the data. REtreiving the data or selecting on the data will cause a performance
hit you may not want to experience.

As long as the data is enclosed in single-quotes and you can guarantee that the
compressed data won't use single-qoutes, then you shouldn't have any problem.
If you urlencode your data you have another degree of obfuscation that will
translate into performance degradation.

Writing a web app based on testing one single connection is a problem waiting to
happen. Don't code with the mis-conception that if it works for one query it
will work for thousands per hour...

--
Michael Austin.
Consultant - Not Available.
Donations still welcomed. Http://www.firstdbasource.com/donations.html
:)

Andy Hassall <andy@andyh.co.uk> wrote in
news:mj9ei0dflun255vp7d6k90a94o02d0h69s@4ax.com:

> The best way depends on which database you are using. Which one is
> it?
>

sorry,

its MySQL

On Sat, 21 Aug 2004 15:02:09 GMT, Oliver Spiesshofer <oliver@email.com> wrote:

>Andy Hassall <andy@andyh.co.uk> wrote in
>news:mj9ei0dflun255vp7d6k90a94o02d0h69s@4ax.com :
>
>> The best way depends on which database you are using. Which one is
>> it?
>
>sorry,
>
>its MySQL

In that case it's the same as any other data you put into MySQL - run it
exactly once through addslashes() (or the practically equivalent
mysql_escape_string()).

--
Andy Hassall / <andy@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool