🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.cppbuilder.database.multi-tier
Article #919

Re: design ideas

#919
From: John Graham
Date: Sat, 19 Aug 2000 00:00
51 lines
2838 bytes
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
Technical Details
Message-ID: <399E5135.88A5308A@salts.navy.mil>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <8nj7nr$bnc6@bornews.borland.com>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fcd2b,9f16877ffddeda62
X-Google-Attributes: gidfcd2b,public
From: John Graham <jgraham@salts.navy.mil>
Subject: Re: design ideas
Date: 2000/08/19
Message-ID: <399E5135.88A5308A@salts.navy.mil>
X-Deja-AN: 660026282
Content-Transfer-Encoding: 7bit
References: <8nj7nr$bnc6@bornews.borland.com>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Organization: U. S. Navy SALTS Project
Mime-Version: 1.0
Newsgroups: borland.public.cppbuilder.database.multi-tier