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

TechTips: Using BDE tables on a local network

Paradox databases can be used easily on a network, and if properly
configured they should run smoothly for months and years.  Here is a
short compendium of the common questions, mistkaes (honest, that started
out as a real tpyo...), and surprises that concern this topic:

[1] "LOCAL SHARE = TRUE"
This setting simply informs BDE that "it is not alone, even on this one
computer."  It assures that BDE uses the file-locking and file-cacheing
protocols that it would use on a shared network, even when the file is
on the local machine.  In my humble, this setting should ALWAYS be
"TRUE" and really, it should have been dropped from BDE (and hot-wired
to "True") a long time ago.

[2] "NET FILE DIR":
This is where BDE stores the file-sharing control file (.LCK files and
.NET files) that is used to coordinate access to tables among the
various users.  Each workstation should have the same setting ... the
only permissible difference should be the file-letter (e.g. "P:" vs.
"Q:"), but not the path.  This directory must be
read/write/create/delete to all users.

[3] (DELPHI) "DBISAVECHANGES," "DBIUSEIDLETIME," ETC:
Search "groups.google.com" for these keys to find -all- about this issue
of interest to Delphi programmers.

[4] (DELPHI) AUTO-REFRESH:
In Paradox for Windows, if one user changes a record, another user will
automatically "see" the change in a few seconds.  This is because
Paradox will automatically refresh the view.  Delphi doesn't do that on
its own, and it can be tricker than you expect (tho' possible) to
replicate this behavior yourself.

[5] CLOSING TIME:
Applications should always be closed cleanly.  Computers should be
logged off at the end of the day (but NOT "automatically logged off by
the server at 6:00:00 PM").  Don't leave the application running
overnight just out of convenience or habit.  Always shut down the
computer, and let it finish shutdown, before turning power off.  Don't
mash the "reset" button at the first sign of trouble.

[6] CLOSING TIME II:
When you need to take the server down, you should always be certain that
all users have been logged-off ... and don't just "log them off," let
them finish their work on their own.

[7] OPERATING SYSTEM VERSIONS:
Computers should be running Windows 98 or better; if Win95, use 95-B.
All workstations and servers should be running =consistent= versions of
Windows.  And, don't be too quick to rush into Win2K or WinXP just
because your computer salesman said so.  When computers are sharing
files on the network, you really want the various versions of the
file-sharing software that are talking to one another to be the same
version or nearly so ... "the buggiest version out there" is the one
that will determine your level of grief, not the least-buggy one.  It
takes only a slight bit of extra effort and a few extra licenses to keep
-many- glitches with -many- applications (not just Paradox) permanently
out of sight.  [And take my word, you DON'T wanna see them!]

----------------------------------------------------------------
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" <info_...@sundialservices.com> wrote in message

news:3C54AEA2.492C@sundialservices.com...

Quote
> [1] "LOCAL SHARE = TRUE"
> This setting simply informs BDE that "it is not alone, even on this one
> computer."  It assures that BDE uses the file-locking and file-cacheing
> protocols that it would use on a shared network, even when the file is
> on the local machine.  In my humble, this setting should ALWAYS be
> "TRUE" and really, it should have been dropped from BDE (and hot-wired
> to "True") a long time ago.

While the general recommendation seems to be *always* set your local share
to TRUE, I have found that this setting makes no difference on Novell (at
least older versions, which my customers are still using) and that on
Win98 peer-to-peer setup I get instant corruption with local share set to
true.  The only way my peer-to-peer users are able to use their tables
without corruption is when they set local share to false.  Has anybody
else had this experience?

Joseph Misko

Re:TechTips: Using BDE tables on a local network


Quote
"Joseph Misko" <REVERSEoksimhpe...@moc.liamtoh> wrote in message

news:0re58.79473

Quote
> While the general recommendation seems to be *always* set your local share
> to TRUE, I have found that this setting makes no difference on Novell (at
> least older versions, which my customers are still using) and that on
> Win98 peer-to-peer setup I get instant corruption with local share set to
> true.  The only way my peer-to-peer users are able to use their tables
> without corruption is when they set local share to false.  Has anybody
> else had this experience?

Local Share only applies to peer-to-peer networks so it doesn't, AFAIK,
affect operations in a Novell environment. I believe this is documented
somewhere in the BDE help files.

In a Win98 environment not having Local Share true on all operating
workstations is, in my experience, a sure way to hose the database. IOW my
experience is the opposite of yours.

Re:TechTips: Using BDE tables on a local network


I get almost instant corruption in a peer-to-peer setting if local share is
_NOT_ set to True on the PC hosting the data if anyone is accessing the
data using the hosting PC.

I haven't had in problems in a file server environment with local share set
to False - as long as nobody is working with data using the server as a
workstation. As a precaution, if Paradox is loaded on the server, I always
set Local Share to True on the server.

"Joseph Misko" <REVERSEoksimhpe...@moc.liamtoh> wrote in
news:0re58.79473$vH6.4257902@bin6.nnrp.aus1.giganews.com:

Quote
> "Sundial Services" <info_...@sundialservices.com> wrote in message
> news:3C54AEA2.492C@sundialservices.com...
>> [1] "LOCAL SHARE = TRUE"
>> This setting simply informs BDE that "it is not alone, even on this
>> one computer."  It assures that BDE uses the file-locking and
>> file-cacheing protocols that it would use on a shared network, even
>> when the file is on the local machine.  In my humble, this setting
>> should ALWAYS be "TRUE" and really, it should have been dropped from
>> BDE (and hot-wired to "True") a long time ago.

> While the general recommendation seems to be *always* set your local
> share to TRUE, I have found that this setting makes no difference on
> Novell (at least older versions, which my customers are still using)
> and that on Win98 peer-to-peer setup I get instant corruption with
> local share set to true.  The only way my peer-to-peer users are able
> to use their tables without corruption is when they set local share to
> false.  Has anybody else had this experience?

> Joseph Misko

Re:TechTips: Using BDE tables on a local network


In the case you describe, Jeff, you are "logged on to the server."  So
even though the drive, to -you-, is a local drive, it is mandatory that
Paradox obey the same file-locking and file-cacheing protocols that it
would use if the data were not on a local (to you...) drive.  This is
precisely what LOCAL SHARE = TRUE orders it to do.

In a Novell environment, Joseph, no one can be "logged on to the server"
because "'being a fileserver' is the only thing that the server-computer
on a Novell network actually does."  (And damn, don't it do it well...
but that's all it does.)

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

The overhead that this option was designed to allow you to avoid, simply
is of no consequence today.

Quote
>Jeff Shoaf wrote:

> I get almost instant corruption in a peer-to-peer setting if local share is
> _NOT_ set to True on the PC hosting the data if anyone is accessing the
> data using the hosting PC.

> I haven't had in problems in a file server environment with local share set
> to False - as long as nobody is working with data using the server as a
> workstation. As a precaution, if Paradox is loaded on the server, I always
> set Local Share to True on the server.

----------------------------------------------------------------
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


How does one set LOCAL SHARE=TRUE on the server, in particular if Paradox is
not installed on the server?

Jean

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

news:3C55DC6A.416@sundialservices.com...
Quote
> In the case you describe, Jeff, you are "logged on to the server."  So
> even though the drive, to -you-, is a local drive, it is mandatory that
> Paradox obey the same file-locking and file-cacheing protocols that it
> would use if the data were not on a local (to you...) drive.  This is
> precisely what LOCAL SHARE = TRUE orders it to do.

> In a Novell environment, Joseph, no one can be "logged on to the server"
> because "'being a fileserver' is the only thing that the server-computer
> on a Novell network actually does."  (And damn, don't it do it well...
> but that's all it does.)

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

> The overhead that this option was designed to allow you to avoid, simply
> is of no consequence today.

> >Jeff Shoaf wrote:

> > I get almost instant corruption in a peer-to-peer setting if local share
is
> > _NOT_ set to True on the PC hosting the data if anyone is accessing the
> > data using the hosting PC.

> > I haven't had in problems in a file server environment with local share
set
> > to False - as long as nobody is working with data using the server as a
> > workstation. As a precaution, if Paradox is loaded on the server, I
always
> > set Local Share to True on the server.
> ----------------------------------------------------------------
> Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
> mailto:i...@sundialservices.com  (PGP public key available.)
> > 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


I think you don't bother. The O/S sharing software and the .lck and .net
files take care of it. It's only if you're running Paradox and/or other BDE
applications on the file server that you need to worry. I'm running a
Linux/Samba paradox file server without paradox or the BDE and it's worked
withou re-booting and without requiring table rebuilds for over 6 months.

--
Tom Krieg

Don't reply to TAKT, it's a trash can for SPAM.
Reply to tomkrieg instead.

Quote
Jean Friedberg <tpm2...@home.com> wrote in message

news:nun58.11422$8d1.4557472@news1.rdc1.md.home.com...
Quote
> How does one set LOCAL SHARE=TRUE on the server, in particular if Paradox
is
> not installed on the server?

> Jean

> "Sundial Services" <info_...@sundialservices.com> wrote in message
> news:3C55DC6A.416@sundialservices.com...
> > In the case you describe, Jeff, you are "logged on to the server."  So
> > even though the drive, to -you-, is a local drive, it is mandatory that
> > Paradox obey the same file-locking and file-cacheing protocols that it
> > would use if the data were not on a local (to you...) drive.  This is
> > precisely what LOCAL SHARE = TRUE orders it to do.

> > In a Novell environment, Joseph, no one can be "logged on to the server"
> > because "'being a fileserver' is the only thing that the server-computer
> > on a Novell network actually does."  (And damn, don't it do it well...
> > but that's all it does.)

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

> > The overhead that this option was designed to allow you to avoid, simply
> > is of no consequence today.

> > >Jeff Shoaf wrote:

> > > I get almost instant corruption in a peer-to-peer setting if local
share
> is
> > > _NOT_ set to True on the PC hosting the data if anyone is accessing
the
> > > data using the hosting PC.

> > > I haven't had in problems in a file server environment with local
share
> set
> > > to False - as long as nobody is working with data using the server as
a
> > > workstation. As a precaution, if Paradox is loaded on the server, I
> always
> > > set Local Share to True on the server.
> > ----------------------------------------------------------------
> > Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
> > mailto:i...@sundialservices.com  (PGP public key available.)
> > > 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


Tom,

Thanks.  That's what I have assumed.

Jean

Quote
"Tom Krieg" <T...@telstra.com> wrote in message

news:a3554o$1649pm$1@ID-129188.news.dfncis.de...
Quote
> I think you don't bother. The O/S sharing software and the .lck and .net
> files take care of it. It's only if you're running Paradox and/or other
BDE
> applications on the file server that you need to worry. I'm running a
> Linux/Samba paradox file server without paradox or the BDE and it's worked
> withou re-booting and without requiring table rebuilds for over 6 months.

> --
> Tom Krieg

> Don't reply to TAKT, it's a trash can for SPAM.
> Reply to tomkrieg instead.

> Jean Friedberg <tpm2...@home.com> wrote in message
> news:nun58.11422$8d1.4557472@news1.rdc1.md.home.com...
> > How does one set LOCAL SHARE=TRUE on the server, in particular if
Paradox
> is
> > not installed on the server?

> > Jean

> > "Sundial Services" <info_...@sundialservices.com> wrote in message
> > news:3C55DC6A.416@sundialservices.com...
> > > In the case you describe, Jeff, you are "logged on to the server."  So
> > > even though the drive, to -you-, is a local drive, it is mandatory
that
> > > Paradox obey the same file-locking and file-cacheing protocols that it
> > > would use if the data were not on a local (to you...) drive.  This is
> > > precisely what LOCAL SHARE = TRUE orders it to do.

> > > In a Novell environment, Joseph, no one can be "logged on to the
server"
> > > because "'being a fileserver' is the only thing that the
server-computer
> > > on a Novell network actually does."  (And damn, don't it do it well...
> > > but that's all it does.)

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

> > > The overhead that this option was designed to allow you to avoid,
simply
> > > is of no consequence today.

> > > >Jeff Shoaf wrote:

> > > > I get almost instant corruption in a peer-to-peer setting if local
> share
> > is
> > > > _NOT_ set to True on the PC hosting the data if anyone is accessing
> the
> > > > data using the hosting PC.

> > > > I haven't had in problems in a file server environment with local
> share
> > set
> > > > to False - as long as nobody is working with data using the server
as
> a
> > > > workstation. As a precaution, if Paradox is loaded on the server, I
> > always
> > > > set Local Share to True on the server.
> > > ----------------------------------------------------------------
> > > Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
> > > mailto:i...@sundialservices.com  (PGP public key available.)
> > > > 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


That brings me to another question. (Hints from Sundial most appreciated).

If ever there was a need to rebuild tables being served by a Linux/Samba
file server (or Novell or whatever), what's the best way of checking,
verifying or rebuilding tables? Run the rebuild (or Chimneysweep) on a
workstation and point it to the server alias? Or copy the tables across the
network to a local drive, run the rebuilds on a local drive and then copy
the good tables back to the server?

I've haven't had to think about it lately but .... you never know.

--
Tom Krieg

Don't reply to TAKT, it's a trash can for SPAM.
Reply to tomkrieg instead.

Quote
Tom Krieg <T...@telstra.com> wrote in message

news:a3554o$1649pm$1@ID-129188.news.dfncis.de...
Quote
> I think you don't bother. The O/S sharing software and the .lck and .net
> files take care of it. It's only if you're running Paradox and/or other
BDE
> applications on the file server that you need to worry. I'm running a
> Linux/Samba paradox file server without paradox or the BDE and it's worked
> withou re-booting and without requiring table rebuilds for over 6 months.

> --
> Tom Krieg

> Don't reply to TAKT, it's a trash can for SPAM.
> Reply to tomkrieg instead.

> Jean Friedberg <tpm2...@home.com> wrote in message
> news:nun58.11422$8d1.4557472@news1.rdc1.md.home.com...
> > How does one set LOCAL SHARE=TRUE on the server, in particular if
Paradox
> is
> > not installed on the server?

> > Jean

> > "Sundial Services" <info_...@sundialservices.com> wrote in message
> > news:3C55DC6A.416@sundialservices.com...
> > > In the case you describe, Jeff, you are "logged on to the server."  So
> > > even though the drive, to -you-, is a local drive, it is mandatory
that
> > > Paradox obey the same file-locking and file-cacheing protocols that it
> > > would use if the data were not on a local (to you...) drive.  This is
> > > precisely what LOCAL SHARE = TRUE orders it to do.

> > > In a Novell environment, Joseph, no one can be "logged on to the
server"
> > > because "'being a fileserver' is the only thing that the
server-computer
> > > on a Novell network actually does."  (And damn, don't it do it well...
> > > but that's all it does.)

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

> > > The overhead that this option was designed to allow you to avoid,
simply
> > > is of no consequence today.

> > > >Jeff Shoaf wrote:

> > > > I get almost instant corruption in a peer-to-peer setting if local
> share
> > is
> > > > _NOT_ set to True on the PC hosting the data if anyone is accessing
> the
> > > > data using the hosting PC.

> > > > I haven't had in problems in a file server environment with local
> share
> > set
> > > > to False - as long as nobody is working with data using the server
as
> a
> > > > workstation. As a precaution, if Paradox is loaded on the server, I
> > always
> > > > set Local Share to True on the server.
> > > ----------------------------------------------------------------
> > > Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
> > > mailto:i...@sundialservices.com  (PGP public key available.)
> > > > 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
"Jean Friedberg" <tpm2...@home.com> wrote in message

news:nun58.11422$8d1.4557472@news1.rdc1.md.home.com...

Quote
> How does one set LOCAL SHARE=TRUE on the server, in particular if Paradox
is
> not installed on the server?

Local Share only needs to be set true on any workstation on which the BDE is
run, i.e. any station that will run your application.

Re:TechTips: Using BDE tables on a local network


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

Quote
>Bruce Roberts wrote:

> "Jean Friedberg" <tpm2...@home.com> wrote in message
> news:nun58.11422$8d1.4557472@news1.rdc1.md.home.com...
> > How does one set LOCAL SHARE=TRUE on the server, in particular if Paradox
> is
> > not installed on the server?

> Local Share only needs to be set true on any workstation on which the BDE is
> run, i.e. any station that will run your application.

----------------------------------------------------------------
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


It's according to how fast your network is, how big your tables are, and
how many indices are on the table. To rebuild the table on the server,
you've got to move the data across the network multiple times - and each
index requires more traffic. For small tables with a fast network, this
ain't that big of a deal -  you probably won't save enough time to make up
for the time it takes to manually do the copy.

For large tables (100K's of records, > 400K of disk space) with multiple
indices, it'll almost always be faster to copy the data to your local hard
drive, do the repair, then copy it back.

"Tom Krieg" <T...@telstra.com> wrote in
news:a35et5$15sgn4$1@ID-129188.news.dfncis.de:

Quote
> That brings me to another question. (Hints from Sundial most
> appreciated).

> If ever there was a need to rebuild tables being served by a
> Linux/Samba file server (or Novell or whatever), what's the best way of
> checking, verifying or rebuilding tables? Run the rebuild (or
> Chimneysweep) on a workstation and point it to the server alias? Or
> copy the tables across the network to a local drive, run the rebuilds
> on a local drive and then copy the good tables back to the server?

> I've haven't had to think about it lately but .... you never know.

> --
> Tom Krieg

> Don't reply to TAKT, it's a trash can for SPAM.
> Reply to tomkrieg instead.

> Tom Krieg <T...@telstra.com> wrote in message
> news:a3554o$1649pm$1@ID-129188.news.dfncis.de...
>> I think you don't bother. The O/S sharing software and the .lck and
>> .net files take care of it. It's only if you're running Paradox and/or
>> other BDE applications on the file server that you need to worry. I'm
>> running a Linux/Samba paradox file server without paradox or the BDE
>> and it's worked withou re-booting and without requiring table rebuilds
>> for over 6 months.

>> --
>> Tom Krieg

>> Don't reply to TAKT, it's a trash can for SPAM.
>> Reply to tomkrieg instead.

>> Jean Friedberg <tpm2...@home.com> wrote in message
>> news:nun58.11422$8d1.4557472@news1.rdc1.md.home.com...
>> > How does one set LOCAL SHARE=TRUE on the server, in particular if
>> > Paradox is not installed on the server?

>> > Jean

>> > "Sundial Services" <info_...@sundialservices.com> wrote in message
>> > news:3C55DC6A.416@sundialservices.com...
>> > > In the case you describe, Jeff, you are "logged on to the server."
>> > >  So even though the drive, to -you-, is a local drive, it is
>> > > mandatory that Paradox obey the same file-locking and
>> > > file-cacheing protocols that it would use if the data were not on
>> > > a local (to you...) drive. This is precisely what LOCAL SHARE =
>> > > TRUE orders it to do.

>> > > In a Novell environment, Joseph, no one can be "logged on to the
>> > > server" because "'being a fileserver' is the only thing that the
>> > > server-computer on a Novell network actually does."  (And damn,
>> > > don't it do it well... but that's all it does.)

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

>> > > The overhead that this option was designed to allow you to avoid,
>> > > simply is of no consequence today.

>> > > >Jeff Shoaf wrote:

>> > > > I get almost instant corruption in a peer-to-peer setting if
>> > > > local share is _NOT_ set to True on the PC hosting the data if
>> > > > anyone is accessing the data using the hosting PC.

>> > > > I haven't had in problems in a file server environment with
>> > > > local share set to False - as long as nobody is working with
>> > > > data using the server as a workstation. As a precaution, if
>> > > > Paradox is loaded on the server, I always set Local Share to
>> > > > True on the server.
>> > > ----------------------------------------------------------------
>> > > Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
>> > > mailto:i...@sundialservices.com  (PGP public key available.)
>> > > > 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


Sundial Services <info_...@sundialservices.com> wrote in
news:3C55DC6A.416@sundialservices.com:
If you have any non-shared tables that aren't in your private directory on
your local hard drive, setting Local Share to True turns off the BDE's
write caching on these tables. If you're working with any these tables, the
caching can make a big difference in performance. If you're doing any big
data imports, exports, copies, etc. with tables that aren't in the private
directory, you definately want to have Local Share set to False, especially
if you've boosted the BDE memory settings significantly.

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

Quote
> In the case you describe, Jeff, you are "logged on to the server."  So
> even though the drive, to -you-, is a local drive, it is mandatory that
> Paradox obey the same file-locking and file-cacheing protocols that it
> would use if the data were not on a local (to you...) drive.  This is
> precisely what LOCAL SHARE = TRUE orders it to do.

> In a Novell environment, Joseph, no one can be "logged on to the
> server" because "'being a fileserver' is the only thing that the
> server-computer on a Novell network actually does."  (And damn, don't
> it do it well... but that's all it does.)

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

> The overhead that this option was designed to allow you to avoid,
> simply is of no consequence today.

>>Jeff Shoaf wrote:

>> I get almost instant corruption in a peer-to-peer setting if local
>> share is _NOT_ set to True on the PC hosting the data if anyone is
>> accessing the data using the hosting PC.

>> I haven't had in problems in a file server environment with local
>> share set to False - as long as nobody is working with data using the
>> server as a workstation. As a precaution, if Paradox is loaded on the
>> server, I always set Local Share to True on the server.
> ----------------------------------------------------------------
> Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
> mailto:i...@sundialservices.com  (PGP public key available.)
>> 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


Interesting, and good to know.

My own experience has been that Windows cacheing alone is usually
sufficient.  I have gobs of RAM in all the machines and the cache
settings are turned way up high.

What makes the biggest difference for me, with large imports etc, is to
remove all indexes from the table and put them back again afterwards.
It takes much less time to build a new index on 100,000 records than it
does to perform 100,000 inserts with an index-update occurring for each
one.

I also physically sort the records into what will be the new primary-key
order before creating that key.  This avoids block-splits that would
otherwise occur when creating the index.

Quote
>Jeff Shoaf wrote:

> Sundial Services <info_...@sundialservices.com> wrote in
> news:3C55DC6A.416@sundialservices.com:
> If you have any non-shared tables that aren't in your private directory on
> your local hard drive, setting Local Share to True turns off the BDE's
> write caching on these tables. If you're working with any these tables, the
> caching can make a big difference in performance. If you're doing any big
> data imports, exports, copies, etc. with tables that aren't in the private
> directory, you definately want to have Local Share set to False, especially
> if you've boosted the BDE memory settings significantly.

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

----------------------------------------------------------------
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


Jeff,

Be very careful with this.  It could leave to problems with multiple sessions,
applications, and (yes) users on peer-to-peer networks.

To my mind, the performance decrease is negligible compared to the data
integrity benefits.

YMMV, just be careful.

-- Lance

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

Go to page: [1] [2]

Other Threads