Why not having several copies of a table owned by different users?

[Eric Mamet]

We have an ASP application using SQL Server 2000 through stored procs.
We'd like to make this application multilingle and have come up with a few
schemes.

We'd like to minimise (eliminate!) changes at the ASP Front end because it
would be expensive in many ways.
For this reason, we don't want to make combined keys by adding a Language Id
in our lookup tables.

One scheme involves creating duplicate tables of our lookup tables owned by
different users (FrenchUser, UKUser, etc) and changing the database
connection string depending on the language.

I don't like this idea AT ALL but I fail to convince my mates!
Could you help?

We have already identified that we'll need to also make copies of the stored
procs so that they look at the "right" underlying table.
That already seems too messy... (cut and paste technology...)

Does someone knows exactly why this sort of thing (using tables owned by
various users) has such bad reputation?

Thanks

PS: I think I have a better scheme but I don't want to bore you all with it!
I just need to kill the idea above...

[SriSamp]

For one, you need not have different tables "owned" by different users. If
your application provides the user the ability to choose the language, you
can just pass this in as a parameter to all stored procedures so that they
can decide internally what tables to look into. Since the table names will
not be known until runtime, you would use dynamic SQL to achieve this...
--
HTH,
SriSamp
Please reply to the whole group only!

"Eric Mamet" <eric.mam...@edev.co.uk> wrote in message
news:OWXJaVIG...@TK2MSFTNGP12.phx.gbl...

[Jacco Schalkwijk]

> We'd like to minimise (eliminate!) changes at the ASP Front end because it
> would be expensive in many ways.

Why expensive? The only thing you have to do is change some stored
procedures so they accept an extra parameter that indicates the language of
the user, so you can just use one version of your lookup table with an extra
language column.

You can easily find the occurances of these stored procedures in your ASP
code with a search and adding one parameter, the value of which you keep in
a session variable I assume, to them is not much work; the code will
probably be identical for each procedure call. One of the reasons for using
stored procedures is exactly that it makes these kind of changes relatively
painless in the client application.

--
Jacco Schalkwijk MCDBA, MCSD, MCSE
Database Administrator
Eurostop Ltd.

"Eric Mamet" <eric.mam...@edev.co.uk> wrote in message
news:OWXJaVIG...@TK2MSFTNGP12.phx.gbl...

[Eric Mamet]

I completely agree with your comments but I run out of arguments.

Of course, I would rather add one param to the relevant stored procs but I
don't seem to have much success explaining this...

"Jacco Schalkwijk" <NOSPAM...@eurostop.co.uk> wrote in message
news:eH%23qlxIG...@tk2msftngp13.phx.gbl...