Board index » delphi » TechTips: Using BDE tables on a local network

TechTips: Using BDE tables on a local network

Quote
Jeff Shoaf <jeffsh...@alltel.net> wrote in message

news:Xns91A577881A9Djeffshoafalltel.net@207.91.5.10...

Quote
> Sundial Services <info_...@sundialservices.com> wrote in
> news:3C55DC6A.416@sundialservices.com:

> And I always turn Local Share off on my non-shared development PCs
for that
> very reason...

> > So basically I stand by my recommendation:  "LOCAL SHARE = TRUE for
> > EVERYone, =no= exceptions."

My applications refuse to run with LOCAL SHARE = FALSE, or more
precise, set LOCAL SHARE=TRUE, force a subsequent exit and
reloading of the program. To my mind, this is the only reasonable
way to handle it.

Peter Reber

 

Re:TechTips: Using BDE tables on a local network


Quote
Sundial Services wrote:

> Exactly... and if Paradox IS installed on that server, then LOCAL SHARE
> _must be set to TRUE in that computer's configuration.

The question originally was about BDE cache flushing and
record lockings, then what exact meaning has Paradox here ?

Does that 'Paradox' refer to Paradox for Windows development
system, or Paradox tables?

My understanding is that neither Paradox for Windows, and surely
at least Paradox tables themselves can't act as a Server.

So why should it still be that mandatory for that server to
have Local Share = True turned on?

You don't even have any sensible means to turn it on.
In case that computer really acts just as a server, and
not as a combined server/workstation.

There's some misunderstanding, but where exactly?

Markku Nevalainen

Re:TechTips: Using BDE tables on a local network


You are correct that "the server" in this configuration isn't a database
server -- the Paradox system does not support client-server operation as
you well know.

What I mean is, if the computer upon which the shared-drive physically
resides .. the computer for which the shared-drive IS "its local
C-drive" .. posesses a copy of Paradox (or BDE) and is used from time to
execute applications which use it, then it is imperative that "Local
Share = True."

This setting advises BDE that, even though this drive is not (to this
computer) a "network" drive, network file-sharing and locking semantics
should be followed.  This is necessary so that the application that
happens to be executing upon this computer will interact properly with
the other applications who are accessing the system as a shared-drive.

This setting is also necessary anytime two applications on the same
computer are using BDE simultaneously.

Practically speaking, I think it should be True all the time in all
cases.  Others, as the record shows, somewhat disagree with me.

Quote
Markku Nevalainen wrote:

> Sundial Services wrote:

> > Exactly... and if Paradox IS installed on that server, then LOCAL SHARE
> > _must be set to TRUE in that computer's configuration.

> The question originally was about BDE cache flushing and
> record lockings, then what exact meaning has Paradox here ?

> Does that 'Paradox' refer to Paradox for Windows development
> system, or Paradox tables?

> My understanding is that neither Paradox for Windows, and surely
> at least Paradox tables themselves can't act as a Server.

> So why should it still be that mandatory for that server to
> have Local Share = True turned on?

> You don't even have any sensible means to turn it on.
> In case that computer really acts just as a server, and
> not as a combined server/workstation.

> There's some misunderstanding, but where exactly?

Re:TechTips: Using BDE tables on a local network


With JSI, Paradox essentially becomes both the client and the server.
<g>

--
Tony McGuire
<brag>I've Met Liz</brag>
 http://www.thedbcommunity.com
 http://www.thedbaddons.com/jsip
__________________

Quote
"Sundial Services" <info_...@sundialservices.com> wrote in message

news:3C58C472.2323@sundialservices.com...
Quote
> You are correct that "the server" in this configuration isn't a
database
> server -- the Paradox system does not support client-server
operation as
> you well know.

> What I mean is, if the computer upon which the shared-drive
physically
> resides .. the computer for which the shared-drive IS "its local
> C-drive" .. posesses a copy of Paradox (or BDE) and is used from
time to
> execute applications which use it, then it is imperative that "Local
> Share = True."

> This setting advises BDE that, even though this drive is not (to
this
> computer) a "network" drive, network file-sharing and locking
semantics
> should be followed.  This is necessary so that the application that
> happens to be executing upon this computer will interact properly
with
> the other applications who are accessing the system as a
shared-drive.

> This setting is also necessary anytime two applications on the same
> computer are using BDE simultaneously.

> Practically speaking, I think it should be True all the time in all
> cases.  Others, as the record shows, somewhat disagree with me.

> Markku Nevalainen wrote:

> > Sundial Services wrote:

> > > Exactly... and if Paradox IS installed on that server, then
LOCAL SHARE
> > > _must be set to TRUE in that computer's configuration.

> > The question originally was about BDE cache flushing and
> > record lockings, then what exact meaning has Paradox here ?

> > Does that 'Paradox' refer to Paradox for Windows development
> > system, or Paradox tables?

> > My understanding is that neither Paradox for Windows, and surely
> > at least Paradox tables themselves can't act as a Server.

> > So why should it still be that mandatory for that server to
> > have Local Share = True turned on?

> > You don't even have any sensible means to turn it on.
> > In case that computer really acts just as a server, and
> > not as a combined server/workstation.

> > There's some misunderstanding, but where exactly?

Re:TechTips: Using BDE tables on a local network


Your product certainly sounds very, very interesting.  Wish I had
invented it.

Quote
>Tony McGuire wrote:

> With JSI, Paradox essentially becomes both the client and the server.
> <g>

> --
> Tony McGuire
> <brag>I've Met Liz</brag>
>  http://www.thedbcommunity.com
>  http://www.thedbaddons.com/jsip

----------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:i...@sundialservices.com  (PGP public key available.)
Quote
> Fast(!), automatic table-repair with two clicks of the mouse!
> ChimneySweep(R):  Release 4.0 is here!!
> http://www.sundialservices.com/products/chimneysweep

Re:TechTips: Using BDE tables on a local network


Quote
Sundial Services wrote:

> What I mean is, if the computer upon which the shared-drive physically
> resides .. the computer for which the shared-drive IS "its local
> C-drive" .. posesses a copy of Paradox (or BDE) and is used from time to
> execute applications which use it, then it is imperative that "Local
> Share = True."

I still wonder what do you mean by 'Paradox' here. Paradox can mean
a certain database structure. Like "dBase-IV data structure" means a
certain database structure, how the data is or organised and saved
inside those .DBF files and their indexes.

Alternatively 'Paradox' can mean the Paradox for Windows development
system. And possibly it can also mean the runtime parts of it, that
needs to be installed on the target PC, before you can run applications
made with Paradox for Windows.

But neither of these have no meaning, when we are talking about BDE
buffer flushing, and Local Share settings. That's why I'm wondering, what
does mean the comment, 'if Paradox IS installed on that server'.

Quote
> This setting advises BDE that, even though this drive is not (to this
> computer) a "network" drive, network file-sharing and locking semantics
> should be followed.  This is necessary so that the application that
> happens to be executing upon this computer will interact properly with
> the other applications who are accessing the system as a shared-drive.

As a matter, the *server PC* does not have to have any part of BDE
nor Paradox for Windows runtime installed, to be able to share Paradox
database for Delphi written, or Paradox for Windows written applications.

The server will never load any parts of BDE or any parts of Paradox for
Windows runtime libraries in to the it's own RAM-memory.

For program execution and DB usage, the BDE parts will always be loaded
_only_ to the Workstation computers' RAM memory.

In case when the server works as a combined server/workstation, then
also it does load those BDE parts, as any of the other workstations.
But even then, the server's loaded BDE does not perform any tasks for
the other workstations.

So there is absolutely no meaning, what kind of Local Share settings
you have on a pure server PC. The role of the pure server PC is to act
as a shared disk storage only. It's just a shared dummy IDE hard disk,
residing at the other end of the company's ethernet cable.

It never processes any of the data in it's own CPU. Just allows the
workstations to get to it's hard disk, and allows workstations to
put their record lockings, and allows them to flush their buffers
(Local share=True) to the database etc.

So the only active role for BDE is in the workstations only. Workstations
must all have their Local Share =True turned on.

Quote
> This setting is also necessary anytime two applications on the same
> computer are using BDE simultaneously.

Yes, but the setting is mandatory for the workstations only.

LocalShare=True setting being on at the Server has no meaning. No
process within the workstations nor at the server will never read
that setting, nor use it.

---
Well, if I'm badly wrong with this matter, I believe someone will correct
me in no time.

Markku Nevalainen

Re:TechTips: Using BDE tables on a local network


The only fault I find is if Paradox the Application is installed on
the server and run from the workstation(s).

Then is not the BDE on the server?  Or does it have to reside on the
workstation?

Or even if only a shared idapi**.cfg is used.  Is this not then set on
the server?

I, too, await illumination.

--
Tony McGuire
<brag>I've Met Liz</brag>
 http://www.thedbcommunity.com
 http://www.thedbaddons.com/jsip
__________________

Quote
"Markku Nevalainen" <m...@iki.fi> wrote in message

news:3C590EC9.549F@iki.fi...
Quote
> Sundial Services wrote:

> > What I mean is, if the computer upon which the shared-drive
physically
> > resides .. the computer for which the shared-drive IS "its local
> > C-drive" .. posesses a copy of Paradox (or BDE) and is used from
time to
> > execute applications which use it, then it is imperative that
"Local
> > Share = True."

> I still wonder what do you mean by 'Paradox' here. Paradox can mean
> a certain database structure. Like "dBase-IV data structure" means a
> certain database structure, how the data is or organised and saved
> inside those .DBF files and their indexes.

> Alternatively 'Paradox' can mean the Paradox for Windows development
> system. And possibly it can also mean the runtime parts of it, that
> needs to be installed on the target PC, before you can run
applications
> made with Paradox for Windows.

> But neither of these have no meaning, when we are talking about BDE
> buffer flushing, and Local Share settings. That's why I'm wondering,
what
> does mean the comment, 'if Paradox IS installed on that server'.

> > This setting advises BDE that, even though this drive is not (to
this
> > computer) a "network" drive, network file-sharing and locking
semantics
> > should be followed.  This is necessary so that the application
that
> > happens to be executing upon this computer will interact properly
with
> > the other applications who are accessing the system as a
shared-drive.

> As a matter, the *server PC* does not have to have any part of BDE
> nor Paradox for Windows runtime installed, to be able to share
Paradox
> database for Delphi written, or Paradox for Windows written
applications.

> The server will never load any parts of BDE or any parts of Paradox
for
> Windows runtime libraries in to the it's own RAM-memory.

> For program execution and DB usage, the BDE parts will always be
loaded
> _only_ to the Workstation computers' RAM memory.

> In case when the server works as a combined server/workstation, then
> also it does load those BDE parts, as any of the other workstations.
> But even then, the server's loaded BDE does not perform any tasks
for
> the other workstations.

> So there is absolutely no meaning, what kind of Local Share settings
> you have on a pure server PC. The role of the pure server PC is to
act
> as a shared disk storage only. It's just a shared dummy IDE hard
disk,
> residing at the other end of the company's ethernet cable.

> It never processes any of the data in it's own CPU. Just allows the
> workstations to get to it's hard disk, and allows workstations to
> put their record lockings, and allows them to flush their buffers
> (Local share=True) to the database etc.

> So the only active role for BDE is in the workstations only.
Workstations
> must all have their Local Share =True turned on.

> > This setting is also necessary anytime two applications on the
same
> > computer are using BDE simultaneously.

> Yes, but the setting is mandatory for the workstations only.

> LocalShare=True setting being on at the Server has no meaning. No
> process within the workstations nor at the server will never read
> that setting, nor use it.

> ---
> Well, if I'm badly wrong with this matter, I believe someone will
correct
> me in no time.

> Markku Nevalainen

Re:TechTips: Using BDE tables on a local network


Quote
Tony McGuire wrote:

> The only fault I find is if Paradox the Application is installed on
> the server and run from the workstation(s).

Case when your own BDE based DB-application, the EXE-file itself,
lies on the server hard. And you start this application from a Workstation,
that is from another PC on the net.

Then the workstation get's the EXE file through the net, from the
server's hard disk, and loads it to the Workstation's RAM-memory.

The application notices, that hey, I am a BDE-application, and now
I need quickly to load those BDE parts in to the Workstation's RAM
memory.
Those several .DLL files, that consist the BDE, can reside on the
Workstations own hard disk, or also they could reside on the server's
hard disk.

Quote
> Then is not the BDE on the server?  Or does it have to reside on the
> workstation?
> Or even if only a shared idapi**.cfg is used.  Is this not then set on
> the server?

All right, this is the case when the Local Share setting in the server's
IDAPI32.CFG file has effect.
Case where the workstations load also the BDE files through the net, from
the server's hard disk, and there is the only available IDAPI32.CFG file.

Then the workstations do read the settings from there, and get their
own Local Share=True setting initialized.

I always install the BDE files, and then also the IDAPI.CFG file to the
workstation's own hard disk. This leaves the network delay away, and
the app starts a little faster.

Markku Nevalainen

Re:TechTips: Using BDE tables on a local network


For purposes of this conversation, the "server" PC is a file server, not a
database server ala' a client/server database server. The Local Share
setting is a BDE setting and relevant to any app using the BDE, but this
newsgroup is geared towards "Paradox the RDBMS" more than "Paradox the
table format", so the discussion is coming from a "Paradox the RDBMS"
viewpoint.

Regardless of where the BDE or Paradox files and .dll's or data reside,
Paradox and the BDE run on the local workstation. The Local Share setting
controls how the BDE caches data that resides on the workstation's local
hard drive - and yes, the BDE knows whether the data is on a local or
remote hard drive. If the data resides on the local hard drive, the BDE
uses a cache for the data. When the BDE writes data to a record in a table
on a local hard drive with local share off, it writes to the cache and not
directly to the disk. It will flush the data to disk in response to certain
defined actions. If the table is on a remote disk, the data is written to
the table immediately. If the table is on a local disk and another BDE app
on another PC writes to the table, there are now two versions of the table
- one on the disk and one in the local BDE's cache. When the local BDE
flushes it's cache, you have table corruption. Note that the same problem
happens if there are two BDE apps on the same PC attempting two write to
the same table with Local Share turned off; each BDE session has it's own
cache.

With Local Share set to true, the BDE sets it's cache to work in "write-
through" mode - when it writes to the table, it updates both the cache and
the disk.

Note that none of this affects tables in a BDE session's Private directory
- the BDE automatically puts a full lock on each session's Private
directory so that only that session can access the tables in it's own
session.

In other words, it doesn't matter where your app or the BDE files are;
Local Share comes into play based on where the data tables reside in
relation to where the app and/or BDE is running.

Markku Nevalainen <m...@iki.fi> wrote in news:3C594068.25D3@iki.fi:

Quote
> Tony McGuire wrote:

>> The only fault I find is if Paradox the Application is installed on
>> the server and run from the workstation(s).

> Case when your own BDE based DB-application, the EXE-file itself,
> lies on the server hard. And you start this application from a
> Workstation, that is from another PC on the net.

> Then the workstation get's the EXE file through the net, from the
> server's hard disk, and loads it to the Workstation's RAM-memory.

> The application notices, that hey, I am a BDE-application, and now
> I need quickly to load those BDE parts in to the Workstation's RAM
> memory.
> Those several .DLL files, that consist the BDE, can reside on the
> Workstations own hard disk, or also they could reside on the server's
> hard disk.

>> Then is not the BDE on the server?  Or does it have to reside on the
>> workstation? Or even if only a shared idapi**.cfg is used.  Is this
>> not then set on the server?

> All right, this is the case when the Local Share setting in the
> server's IDAPI32.CFG file has effect.
> Case where the workstations load also the BDE files through the net,
> from the server's hard disk, and there is the only available
> IDAPI32.CFG file.

> Then the workstations do read the settings from there, and get their
> own Local Share=True setting initialized.

> I always install the BDE files, and then also the IDAPI.CFG file to the
> workstation's own hard disk. This leaves the network delay away, and
> the app starts a little faster.

> Markku Nevalainen

Re:TechTips: Using BDE tables on a local network


Quote
Jeff Shoaf wrote:

> so the discussion is coming from a "Paradox the RDBMS" viewpoint.

Thanks for this clarification. Both BDE apps written by Delphi and "Paradox the
RDBMS" do their DB actions through the same BDE layer.
So I quess both environments mostly share the same problems. And then both
the Delphi users and "Paradox the RDBMS" users can share the same answers
here.

Quote
> The Local Share setting
> controls how the BDE caches data that resides on the workstation's local
> hard drive - and yes, the BDE knows whether the data is on a local or
> remote hard drive.

I think Borland even today has not given out the description, how BDE actually
handles the data chunks. So the information above is quite interesting, and also
new info to me.
But I'll also have to ask, do you happen to have any link to some source, that
could in any way confirm this part of the BDE behaviour?

Quote
> If the data resides on the local hard drive, the BDE
> uses a cache for the data. When the BDE writes data to a record in a table
> on a local hard drive with local share off, it writes to the cache and not
> directly to the disk. It will flush the data to disk in response to certain
> defined actions. If the table is on a remote disk, the data is written to
> the table immediately.

Here is something that needs a bit clarification. The earlier info, that BDE
always knows if a table is behind a network. And this last sentence, that it also
automatically immediately writes data to all the tables, that it knows are
remote tables.

If this is true, then in cases where all the tables are on a remote disk,
the developer should never be worried if the Local Share is turned On or
Off.
Because BDE automatically knows they are netword tables, and then it know
immediately to write all the changes to them, without caching.

Or what does this exactly mean ??  Ihave always thought, that setting
Local Share=True will automatically write the changes, to both the local
and remote tables, immediately to the hard disk.

Quote
> Note that none of this affects tables in a BDE session's Private directory
> - the BDE automatically puts a full lock on each session's Private
> directory so that only that session can access the tables in it's own
> session.

I was in the understanding, that BDE session does not actually lock the tables
in the Private Directory.
But the developer must ensure, that when creating each new BDE session, must
ensure this session will get it's own private directory. And thus the different
BDE sessions do not even see the contents of the other sessions' Private
Directories.

Gee, I really hope, Borland (or Corel) would still be available, and interested
about the BDE related questions. Then they could quickly and easily say the
last word about many of the BDE behaviours.

Markku Nevalainen

Go to page: [1] [2]

Other Threads