How do I expunge all SQL code from a database?

[Breck_Carter]

I want to ship an 11.0.1.2276 *.db file to another party without any of the procedural code still visible to even a binary editor.

I can use ALTER ... SET HIDDEN but that just obfuscates and the recipient is rather clever.

I suspect DROP may not do much of anything to the system catalog data and extension pages other than mark them as free.

Should I use ALTER to replace every procedure, trigger, event, service etcetera with big fat meaningless templates, thus overwriting everything?

Or is that still not going to work?

[VolkerBarth]

So you say ALTER ... SET HIDDEN is not that effective? Should I re-evaluate that part of my answer, cf. http://sqlanywhere-forum.sap.com/questions/1163#1167?

[Breck_Carter]

It's obfuscation, not encryption... there is no user-supplied key. Plus, the engine needs to be able to parse the SQL code so by definition a de-obfuscation algorithm must exist... it's not a one-way thing. I think it's adequate for protection against casual hackers, but in MY case the intended recipient is awash in PhD-class thinkers 🙂

[VolkerBarth]

@Breck: In my understanding, it's still encryption (in contrast to "one-way" hashing) but with a built-in key so that the engine can decrypt automatically. But nevertheless, I agree it's not strong encryption...

[Breck_Carter]

@Volker: If that is so, the engine contains the key, and the key hasn't changed in a thousand years, right? It could be super duper strong encryption, it doesn't matter if everyone has the key. Besides, the Help uses the word "obfuscate".

[former_SQLA_member1694868]

These are two wild guesses:

1) Can you create a blank db and send only the data over to it? Ship the new "clean" db with the same data contents instead of the original with all the procedural code.

2) Can you unload the db and generate the reload statement then delete what you don't want in the reload and then reload? Ship the newly loaded "clean" db.

[VolkerBarth]

I guess that you don't have that much influence on the contents of "freed pages" or make sure that the pages containing procedural code get overwritten when the procedures are altered. (I don't know whether "free'd pages" are reliably "clean"). So I second Siger's suggestions.

[VolkerBarth]

To add: Would you need something like Sysinternals SDELETE for database objects/pages?

[Breck_Carter]

@Siger: yes, copying the tables but not the procedures to a new database is a perfect solution... except for the fact that I don't want to do that in this case. For various reasons, it's too much work.