🚀 go-pugleaf

Serif,

If you are using a TDatabase component in your application server, and you have
constructed a dispatch interface that will allow your client to communicate to
your app. server, you should be able to construct an app. server method that
will change the database that the TDatabase object connects to.

You can call this method from your client when your user selects the company.
If you want to use the same database for all companies, you'll have to change
the TableName property in each TTable object, or change the SQL statements for
your TQuery objects.  This can all be accomplished through the dispatch
interface as well.

I would suggest that having a separate database for each company is more secure.

BTW if you ever figure out exactly which BDE files are required to eliminate the
"object not found" error, I'd appreciate knowing what they are.  I haven't
started the research yet, but I've got all the files in place that the deploy
document says are required.

I remembered that on my test server I did a full BDE install some time ago,
which is probably why the nTier app. is working on that machine.  Now I've got
to figure out what files are missing from the other servers.  If/when I do, I'll
let you know.

Regards,
John

Serif Selcuk wrote:

> Hi,
>
> My accounting application must handle data belonging to different companies.
> It seems to me there are at least two ways to do that:
>
> 1. Having identically structured databases, each keeping the accounting data
> belonging to different company. When user log in, he/she will select which
> company he/she is interested and the application will connect to relevant
> database. This is easy with two-tired application since each client can have
> a seperate connection to database. But I could not find an easy way to do
> this with three-tier architecture since all the clients share the same
> database connection.
>
> 2. A single database will hold the accounting data for all the companies. In
> each table there will be a column indicating the company that the record
> belong. Using filters, selects etc. application will present relevant data
> too user. This makes it easier to use three-tier architecture.
>
> Any ideas which way I should go?
>
> Serif

Graham,
If one client calls a method in app server to change the database connected,
all other clients will be connected to this new database I think. Since
there is only one instance of the RDM. For each client to connect to
different database there must a seperate instance of the RDM for each
database connection. I am not sure I can have that.
I would appreciate if you find files to be deployed in the server. We will
let you know if we find it earlier.
Serif
"John Graham" <jgraham@salts.navy.mil> wrote in message
news:399E5135.88A5308A@salts.navy.mil...
> Serif,
>
> If you are using a TDatabase component in your application server, and you
have
> constructed a dispatch interface that will allow your client to
communicate to
> your app. server, you should be able to construct an app. server method
that
> will change the database that the TDatabase object connects to.
>
> You can call this method from your client when your user selects the
company.
> If you want to use the same database for all companies, you'll have to
change
> the TableName property in each TTable object, or change the SQL statements
for
> your TQuery objects.  This can all be accomplished through the dispatch
> interface as well.
>
> I would suggest that having a separate database for each company is more
secure.
>
> BTW if you ever figure out exactly which BDE files are required to
eliminate the
> "object not found" error, I'd appreciate knowing what they are.  I haven't
> started the research yet, but I've got all the files in place that the
deploy
> document says are required.
>
> I remembered that on my test server I did a full BDE install some time
ago,
> which is probably why the nTier app. is working on that machine.  Now I've
got
> to figure out what files are missing from the other servers.  If/when I
do, I'll
> let you know.
>
> Regards,
> John
>