Based on this question and other situations, I'd like to ask if there have ever been plans to support some of SQL Anywhere's builtin functions as client-side functions, too.

I'm refering to functions like COMPRESS/DECOMPRESS, ENCRYPT/DECRYPT, HASH and others - functions that might be useful outside queries, too. That's what I mean by "client-side": They should be usable without a query that is processed on the database engine. I have no clear idea of the API I'm thinking of - possibly like the DBTools API, but without having to connect with a database.

Those functions should work the same way as the builtin ones (i.e. compressed or encrypted data should be interchangeable, independent whether it was done client-side or server-side). So they could be used instead of typical third party libraries.

Possible use cases would be

  • to compress huge data on the client before it's sent to the server (as in the question cited above)
  • to encrypt/hash credentials or other sensitive data
  • to encode data with BASE64_ENCODE or use HASH to build CRC32 check sums.

As stated, I'm aware that there are lots of third party libraries for these tasks - on the other hand, it seems handy if one could use these fine builtin functions for "outside" tasks, too.

asked 29 May '11, 16:32

Volker%20Barth's gravatar image

Volker Barth
40.1k361549819
accept rate: 34%

As SQL Aynwhere supports different Operating Systems it would be a tough (or even impossible) job to provide a unified interface to these functions. E.g. on Windows it would be easy to implement these helper functions into the .net interface provided by Sybase. Nevertheless this would not be sufficient for all platforms.

Having the needed efforts in mind would you pay an extra fee for this, as you would for a third party toolkit?

(30 May '11, 03:14) Martin
Replies hidden
1

I do not think the API would be a too difficult problem. Compare the DBTools API which is a classic C API available on all platforms (AFAIK). So platform-independence could even be an additional advantage.

Though I agree that for some programming envirnoments, calling such an API is still some effort - as is calling DBTools from Delphi or .Net.

(30 May '11, 03:31) Volker Barth

No, this has never been requested by anyone else and we have no plans to add this support. I'm not sure I see the point of doing this on the client side. We already support compression and encryption of the connection, so your top two possible use cases are moot. I'm not sure what purpose your third use case would serve - are you concerned with data being corrupted?

permanent link

answered 30 May '11, 13:36

Graeme%20Perrow's gravatar image

Graeme Perrow
9.6k379124
accept rate: 54%

1

Well, that's a clear statement:)

Note that I do not think that my top two points are that moot - obviously due to having specified them rather vague:

  1. As to compression: I had the impression from the cited question that connection compression is not as effective as the COMPRESS function for bigger data. If I'm wrong than that point is moot, apparently.

  2. I'm thinking of using encryption to store client-side data (not the given credentials sent to the server) - so they usually would need to be decrypted before a connection is available to do so. (I'm aware that this leads to the "key" question how a key is stored/hidden/whatsoever.)

But of course I appreciate that this suggestion seems quite exotic:)

(30 May '11, 15:45) Volker Barth

FWIW, the great Breck has shown in a great article on his great blog how to simulate such hypothetical client-side functions with a local "dummy" database.

Not really what I was asking for but a possible workaround - as long as there's a local database engine on the client-side, too...

permanent link

answered 02 Jun '11, 18:53

Volker%20Barth's gravatar image

Volker Barth
40.1k361549819
accept rate: 34%

edited 03 Jun '11, 06:07

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×113
×46
×13

question asked: 29 May '11, 16:32

question was seen: 3,178 times

last updated: 03 Jun '11, 06:07