Local Share: True or False in BDE 5?
Marcio Ehrlich
I always learned (from
http://community.borland.com/article/0,1410,15247,00.html , for instance)
that Local Share should be set to TRUE in all stations on a peer-to-peer
network. Many documents says the same.
But these days a member of a Brazilian newsgroup about Delphi reproduced
this information from a 1996 Borland document saying: "Set to TRUE if you
need to work with the same files through both a BDE and a non-BDE
application at the same time. (It is not necessary to set LOCAL SHARE to
TRUE if you do not need to have both applications open at the same time.)
Default: FALSE."
After all, which is the right information?
Thanks,
Marcio
Steven Green
> After all, which is the right information?
set it to TRUE.. we've learned many things since 1996 <g>..
--
Steven Green - Waldorf Maryland USA
Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------
Bill Todd (TeamB)
that are on your local hard drive. It is not necessary to have Local
Share set to true in this situation if all of the applications are
using the 32 bit BDE because they will be sharing the same copy of the
BDE in memory and it will handle locking in memory. However, it is
still a good idea to set Local Share to true because it disables the
BDE write cache. This means that you are much less likely to suffer
table or index corruption if Windows or the PC crashes.
TI15247 is still the correct configuration for peer-to-peer networks.
--
Bill (TeamB)
(TeamB cannot respond to questions received via email)
Marcio Ehrlich
> TI15247 is still the correct configuration for peer-to-peer networks.
Tks,
M.
Steven Green
> However, it is still a good idea to set Local Share to true because it
> disables the
> BDE write cache.
and that's a *really* important reason..
Marcio Ehrlich
cache":
>
> and that's a *really* important reason..
Steve,
Would you mind elaborate a little more why BDE write cache should be
disabled?
TIA.
Marcio
Steven Green
> Would you mind elaborate a little more why BDE write cache should be
> disabled?
because you want all data flushed to disk immediately.. for other apps and for
the app that's running.. mis-matched or failed writes are the source of most
"table and index" errors..
Olivier Beltrami
> disabled?
If it is enabled, you might do a post (or commit) and think all is weel, but
in reality the BDE has not yet saved the data to disk ... so any crash and
your recently posted data is toast.
Olivier
Marcio Ehrlich
> If it is enabled, you might do a post (or commit) and think all is weel,
but
> in reality the BDE has not yet saved the data to disk ... so any crash and
> your recently posted data is toast.
I see. Kinda weird this BDE logic, isn't it?
Tks,
Marcio
Steven Green
> I see. Kinda weird this BDE logic, isn't it?
not really.. remember how old most of it is.. in the old days, we all did every
kind of caching/memory trick we could, to speed things up.. safety wasn't the
first concern, when all we had to work with were 386's.. but, as I said earlier,
we've all learned a lot since then..
Bill Todd (TeamB)
<mehrlichatopenlinkdotcomdotbr> wrote:
>I see. Kinda weird this BDE logic, isn't it?
Not at all. Write caching improves performance. Most medium to large
scale database servers provide it as an option. It is ok to use it as
long as the machine running the database is stable.