> I think a little different...
>
> I have frequently shared data with other applications, I think data MUST

be

> in only one place, if a customer have 2 or 3 different systems developed

by

> diferent software houses they should share the data, I think that using
> illogical names will be a nightmare to you (as Svein has said), and with
> Business Intelligence Tools the user will want to use your data (and don't
> think it's your data but customer data) in a simple and easy way.

Under normal circumstances I would fully agree with you. I love integrating
systems and have a system that shares its data is brilliant. But ( theres
always a but :0) ) the application may be used by more than one person on
the same machine and the data that is stored is confidential per user. So
for example person A is a software developer who knows about Interbase.
Person B uses person A machine and thus uses the same application and
database. Person A falls out with Person B and knows that the data stored in
the database for Person B can seriously damage them so uses the SYSDBA
username and looks at Person B records.

> I think you could remove the stored procedure code.
>
> If your problem is protect yourself from have headaches fixing the changes
> your customer done in your tables, views, etc. I think you should have

made

> an contract that said:
>
> The Database structure is MY and YOU CANNOT CHANGE IT. NO ONE EXCEPT ME

can

> change de data structure !
>
> If you want to protect yourself from other view the way you solved the
> problem by analizing your data structure, I think you have no choice...
> there are MANY DataBase Modelling Tools that can Reverse Engenieer almost
> anything.
>
> As Svein said, if they know SYSDBA password, you have no choice, if they

do

> not know it, but can copy the database to another machine, again, they

have

> full access. I remember something about creating a role named SYSDBA that
> prevents some one to login as SYSDBA on the database, anyone remember this
> ? This trick do what Marcus want ?
>
> I think hide the data structure is not good, as said above, everyone want
> to do the maximum with the data, and needs not only to see the database
> structure but full database documentation, ERD's, comments, relationships
> and constraints...

Yes I am a little concerned about the structure but I'm more concerned about
the data.

> Some customers ask me to send with my proposal the data model for internal
> staff or consultants to analize. I used to think that this is damm bad,
> someone will see my ideas and how I solved the problem, now I think, come
> on, there is more than just data model to solve the problem and I am not
> the only genius in the world, I am sure I have not discovered the wheel in
> my database structure.
>
> Of course people can use your work, can steal ideas, but I think that is
> the price you have to pay sometimes.
>
> Protect yourself, make clear in contracts that the database structure, the
> logic and code in the database is your property and ONLY you can modify it
> if you want it.
>

I think the best thing for me to do is encrypt the data that is sensitive.
Then at least if the database is queried the data cannot be ready as easily.

Thanks for your help.

Regards,
Marcus.