Alternatives to Paradox?
Dominic Dumée
I have a paradox based Delphi app that is suffering from the normal paradox
stability problems that we all know so well. The program (obviously) makes
use of MANY TTables and TQuerys. Now I'd like to convert the program to use
a more stable database management system with the least amount of program
changes.
Would using a BDE replacement help to make paradox more stable?
Alternatively which stable db platform would be the easiest to migrate a
delphi/paradox app to?
Any advice/tips would be appreciated.
Thanks
Dominic
Olivier Beltrami
> delphi/paradox app to?
DBISAM (www.elevatesoft.com). Converting a Paradox app to DBISAM is almost
as easy as doing a search/replace in the source code for TTable and TQuery.
Eventually you will want to make it right by changing to TQueries etc... but
with DBISAM you will quickly have a version that compiles and works (even if
not at optimal speed).
Olivier
Rick Carter
There's no general agreement on the best solution for everyone.
A lot depends on things you haven't told us (size of tables,
number of users, how things are networked, etc.) See the list of
alternatives at http://www.kylecordes.com/bag/
Rick Carter
Rick....@cincww.rcc.org
Chair, Paradox/Delphi SIG, Cincinnati PC Users Group
Dominic Dumée
Very large tables (80,000+ records), 30+ concurrent users, pdox files are
accessed via a shared folder on the 'server'.
"Rick Carter" <Rick....@cincww.rcc.org> wrote in message
news:3f4615f6$1...@newsgroups.borland.com...
Bill Todd
On Fri, 22 Aug 2003 15:37:14 +0200, "Dominic Dumée"
<dom...@psas.co.za> wrote:
>Very large tables (80,000+ records), 30+ concurrent users, pdox files are
>accessed via a shared folder on the 'server'.
For a multiuser app do not consider another file server database. For
stability and performance convert to a database server such as
Advantage (www.advantagedatabase.com) or DBISAM.
I have not used DBISAM but it is very easy to convert a Paradox app to
Advantage and since Advantage supports both naviagational access and
SQL there is no need to convert TTables to TAdsQueries. You get the
same performance with both table and query components.
--
Bill (TeamB)
(TeamB cannot respond to questions received via email)
Liz
and have never had a stability problems. I know numerous Paradox
developers using Samba or Windows for servers who also have no
stability problems. (Environments include equal or more users and as
many records as you report in your other post.)
All the problems Paradox users have reported that I'm aware of are
either due to poor development, untrained users or lazy admins (sys
and network) who don't want to take the time to learn and configure
things properly for using a Paradox-based system. (I will fully
acknowledge that there's a lot of things you have to set up in order
to have a stable Paradox system, but the developer and the admins
should have made a different choice if they weren't willing to do it
right.)
Tired of Paradox getting a bad rap for things that aren't its fault,
Liz
Bill Todd
stable network are the keys to a stable system.
Liz
Liz
Olivier Beltrami
So am I. I have Paradox apps working in the US, Europe, India and China and
they work fine. Granted I have written code to verify each table at opening
and to repair if necessary, but all the tools are there in the API and
looking at other NG it seems no worse to have to write code than to wait for
Borland to release a fix to whatever DB connection tool they are currently
advocating. I'd rather write code than wait powerlessly.
Olivier
Leslie Milburn
"Dominic Dumée" <dom...@psas.co.za> wrote in message
news:3f45...@newsgroups.borland.com...
> Hi
>
> I have a paradox based Delphi app that is suffering from the normal
paradox
> stability problems that we all know so well.
"Normal............We all know so well" ????? Guess what, I don't know this
at all !!!!
I have been using Paradox/BDE in its various incarnations for at least 10
years and have experienced no instability as you would like to call it. The
worst case I ever had was a seriously damaged hard drive (would power on for
a max of three minutes only) and of course no User backup in sight.
The Various tools provided with Paradox meant that there was only ONE HOURS
worth of data loss, try this with another database and see how far you get.
FWIW, I suggest you look closer to home as to why YOU have instability
issues.
Leslie.
bcb
Thanks for your input. Paradox seems to be working better for me than for
some people as well. Other than setting various BDE settings , like Local
Share and all other settings mentioned in this article
http://community.borland.com/article/0,1410,15247,00.html. What else do you
recommend to be set? Have you both personally found that Disabling "new file
sharing and locking semantics" and "write-behind caching" to really help on
Win98(SE)? I've read people recommend and have set those options but does it
add noticeable improvement in stability and does it degrade Windows
performance as the Microsoft tip suggests. I would like to implement them
but still not sure how it will effect older slower machines. Also it seems
that for tables that are open weeks on end and without a single windows
reboot, once in a while it's good to close and open the table. Have some
found that to be true?
Sorry for asking all these questions. Hope you can respond back if you have
the extra time.
Thanks again.
"Liz" <l...@paradoxcommunity.com> wrote in message
news:3F462966...@paradoxcommunity.com...
Bill Todd
On Sun, 24 Aug 2003 09:36:13 -0400, "bcb" <noe...@sorry.com> wrote:
> Have you both personally found that Disabling "new file
>sharing and locking semantics" and "write-behind caching" to really help on
>Win98(SE)?
Yes, on the machine where the tables are located. The two secrets,
aside from proper configuration, are to avoid workstation crashes and
have a stable network.
Steven Green
> Have you both personally found that Disabling "new file sharing and locking
> semantics" and "write-behind caching" to really help on Win98(SE)?
absolutely.. no matter what Win version or configuration, this eliminates most
of the "index out of date" errors..
> I've read people recommend and have set those options but does it add
> noticeable improvement in stability and does it degrade Windows performance as
> the Microsoft tip suggests.
first, we still haven't defined what the "stability" issues are.. second, I've
not seen any degradation of Windows performance in this regard.. maybe it can
degrade the performance of specific other programs, but I'd guess that in the
majority of cases, the program whose performance matters the most is the one
involving Paradox and/or other BDE app..
> Also it seems that for tables that are open weeks on end and without a single
> windows reboot, once in a while it's good to close and open the table.
I've never encountered an app that held local database tables open for weeks on
end.. but just using the generic theory that a crash *can* damage open files, of
course that puts you at greater risk..
--
Steve Green - Diamond Software Group, Inc - Waldorf Maryland USA
Corel CTech Paradox - http://www.diamondsg.com - Support/Downloads/Links
---------------------------------------------------------------------------------
Do you need a Sanity Check? http://www.diamondsg.com/sanity.htm
Upgrade/Downgrade versions? http://www.diamondsg.com/upgrade.htm
-------------------------------------------------------------------------
Olivier Beltrami
this
> at all !!!!
> I have been using Paradox/BDE in its various incarnations for at least 10
> years and have experienced no instability as you would like to call it.
The
> worst case I ever had was a seriously damaged hard drive (would power on
for
> a max of three minutes only) and of course no User backup in sight.
> The Various tools provided with Paradox meant that there was only ONE
HOURS
> worth of data loss, try this with another database and see how far you
get.
I thought I was the last person on Earth to be using Paradox (and liking
it). It's nice to see I am not alone.
Olivier
bcb
"Bill Todd" <n...@no.com> wrote in message
news:krghkv83ocfjm6bgo...@4ax.com...
bcb
some rest this Sunday.
Hi Steven.
Nice to see you still hanging around this place :)
> absolutely.. no matter what Win version or configuration, this eliminates
most
> of the "index out of date" errors..
> first, we still haven't defined what the "stability" issues are..
That's good to hear. Out of 5 Paradox applications I have running I have
this single problem with one. This application usually runs on a single
computer and is run 24 hours a day 7 days a week, I have another app which
is also used as much but shows no corruption problems. A specific table
seems to be prone to corruption call it TableA, it does have indexes but it
is the table itself that gets corrupted. The only difference is that that
TableA is opened most of the time since it's the mostly accessed one, while
the other tables are only opened when needed and that I use TBatchmove to
create a mirror table from TableA and it so happens that the mirror table
also gets corrupted, I didn't expect that, it's not accessed anytime except
when the Batchmove is executed. So it's either the tables or open for too
long or it's the TBatchmove that is the culprit and not any code associated
with TableA.
In one location the same version has run for 6months without any problems
yet, while in the other two it's more often. I'm more sure that this is not
a hardware problem but in my software, I'll set those system file settings
for one computer and change to a newer application version in the other
location. All pc are Win98SE with atleast 128mb of ram and plenty of hard
disk space left.
> I've never encountered an app that held local database tables open for
weeks on
> end.. but just using the generic theory that a crash *can* damage open
files, of
> course that puts you at greater risk..
I agree. I've since added some code where the table in question is closed
and opened between large operations and also added a scheduled weekly reboot
in my application. I just hope it doesn't make things worse, opening and
closing a table hundreds of times per day. I'm still not sure that has
helped, we will see, more thorough testing is needed. I'll respond back if I
find it to work, but that will take at least a few months.
Hope this wasn't too long of a post to read.
Thanks again!
Joe Griffin
> For the record, I've been using Paradox on Novell networks for 9 years
> and have never had a stability problems.
Well said. I have a number of PxWin 4.5 applications still in daily use
and they just go on and on. About the only time in the past 5 years that
there has been a problem was when the Sys Admins rearranged a load of
directories and renamed them "to make the names more logical", without
checking that the names mattered!
The only time we hit a problem with that was in moving from Win 3.1x to
NT4, when the Paradox printer driver failed to cooperate with
orientation changes. (I wrote a Delphi 1 DLL to handle that.) But the
stability of the database was NEVER a problem.
... Joe
Member of the UK Borland User Group
Steven Green
> Wow you guys replied pretty fast, I thought you would be at least getting
> some rest this Sunday.
hey.. when people just happen to post a message 30 seconds before I check for
messages, it always makes me look good <g>
> A specific table seems to be prone to corruption call it TableA, it does have
> indexes but it is the table itself that gets corrupted.
thing one.. the mantra..
the table repair tools are *not* guaranteed to fix every table, every time..
there is no substitute for regular backups..
that said.. what kind of corruption?.. bad block pointer, or something more
sinister?.. have you rebuilt?.. have you exported to ascii and re-imported to a
clean table?..
are there any "warning" messages from the Verify option? stuff like floating
point error, not a number error, memo field errors, low ascii char, etc..
Liz
If you mean Paradox the application (as opposed to just the table
format), check out http://www.thedbcommunity.com/ and
http://www.thedbcommunity.com/support/
Liz
Tony McGuire
: Now I'd like to convert the program to use
: a more stable database management system with the least amount of program
: changes.
:
: Would using a BDE replacement help to make paradox more stable?
: Alternatively which stable db platform would be the easiest to migrate a
: delphi/paradox app to?
You seem to be asking for 'make it a simple conversion'.
Yet your main complaint was 'stability'.
Taking a simple route, aren't you increasing the likelihood that the new app
is slow, as well as unstable?
I'd think you'd want a rewrite to optimize code to the new table platform.
--
--
Paradox Addons http://www.thedbaddons.com
Tony
"I woke up and was able to get myself out of bed.
Being that fortunate, what's to complain about?"
_____________
Liz
My stability configuration recommendations follow. (Note that
stable hardware is key and I haven't addressed it in the list
below.)
> 1. http://www.thedbcommunity.com/faq/13.htm
>
> 2. Oplocks:
> A. NT: http://www.tonymcguire.com/oplocks-nt.htm
> i. UseOpportunisticLocking should be 0
> ii. EnableOplocks should be 0
> iii. The rest don't matter
> B. Win2K/XP: http://www.tonymcguire.com/oplocks-2000.htm
> i. OplocksDisabled should be 1
> ii. EnableOplocks should be 0
> iii. The rest don't matter
> C. Win9x: Control Panel, System applet, Performance tab, File System
> button, Troubleshooting tab, CHECK the boxes labeled:
> i. "Disable new file sharing and locking semantics."
> ii. "Disable write-behind caching for all drives."
> iii. On the Hard Disk tab, you may wish to try setting Read-ahead
> optimization to None, but I think that should only make a difference
> on the server machine.
>
> 3. <removed as it's only relevant to Paradox (the application) apps
> and is relating to refresh issues, not stability> <g>
>
> 4. LOCALSHARE (BDE, Configuration tab, Configuration > System > INIT)
> must be set to TRUE for all users.
>
> 5. Disk caching on Win2K (presumably XP, but I can't check that):
> Properties for the drive, Hardware tab, select the disk of interest,
> click the Properties button, on the Disk Properties tab, UNcheck the
> "Write cache enabled" box if it'll let you.
>
> 6. Make sure the machine serving the .DB files isn't being used as a
> workstation.
NOTE: I can't get #5 to stick (it resets to caching after a
reboot). Not certain it matters. #2 is key on the server/host;
some recommend it for workstations too. #4 is key for all
machines.
I don't know about impact of 2 (I'll take Steve's experience on
that) as this is irrelevant when a NetWare server is serving the
files.
Liz
Liz
In addition to what Steve says, I recall a certain very specific
configuration of block size, primary key and number of records
which could lead to corruption, but I forget the details. I'll
try to find them if you like (you might post the above info and
see if it rings any bells...).
Liz
Dominic Dumée
Don't get me wrong people, I actually like paradox! I've been using paradox
for the last 7 or 8 years and I've become something of an expert on getting
it to be stable. The problem is the app I'm dealing with is installed at
hundreds of different locations and adminstered by people of various
techinal abilities so I have very little control over the hardware
configuration side of things.
The program already checks and adjusts all the documented registry settings
on startup and I've even written my own paradox file repair program (not
using the Borland dll) that directly accesses and interprets the .db file as
I found the dll didn't always recover all the records it could have. But
even after doing all I can in the software the users still complain that
their data gets corrupted due to PCs crashing, power failures, etc, etc.
Now all I'm looking for an alternative that can handle the large number of
records that app deals with in a networked environment without having to
worry so much that the systems aren't configured perfectly. Is that too much
to ask?
Peace
Dominic
Steven Green
> I've even written my own paradox file repair program (not using the Borland
> dll) that directly accesses and interprets the .db file as I found the dll
> didn't always recover all the records it could have.
continued corruption of that nature (losing records) isn't normal..
bcb
> that said.. what kind of corruption?.. bad block pointer, or something
more
> sinister?.. have you rebuilt?.. have you exported to ascii and re-imported
to a
> clean table?..
Don't remember. I'll get the logs and post back.
> are there any "warning" messages from the Verify option? stuff like
floating
> point error, not a number error, memo field errors, low ascii char, etc..
Not that I know of.
Liz
on the planet will survive this! Nor will any client server database
if the PC that crashes due to a power failure and lack of UPS (why not
mix it all together? <g>) is the server PC!
Anyone who complains about these things causing problems ought to have
their computer taken away and replaced with an abacus!
Best of luck to you...
Liz
"Dominic Dumée" wrote:
>
> ... But
Dominic Dumée
> on the planet will survive this! Nor will any client server database
> if the PC that crashes due to a power failure and lack of UPS (why not
> mix it all together? <g>) is the server PC!
Mostly it's the 'client' PCs that crash/hang etc as Windows PCs like to do
for various reasons.
>
> Anyone who complains about these things causing problems ought to have
> their computer taken away and replaced with an abacus!
Indeed. :)
>
> Best of luck to you...
Thanks, it seems I'm going to need it. :)
Cheers
Dominic
bcb
Here is the table structure. There are 4 fields and one index.
Alpha field size=15 and it's the key field
Long Integer -> I have a maintained index for this field
and two timstamp fields.
The table's record count never exceeded 40,000
I've searched the newsgroups
http://groups.google.com/groups?q=block+size+primary+key+corrupt&hl=en&lr=&i
e=UTF-8&oe=UTF-8
and found someone mention this
"Another case is tables with 32 KB blocksize. When the number of records
increases, a corruption may occur"
Is that what you meant to say? that a 32kb blocksize can cause problems in
certain conditions. If it's not too much trouble perhaps you have a
reference to specific newsgroup post?
Thanks very much. I really appreciate all of you taking your time to help
out and share your knowledge.
bcb
have
> > indexes but it is the table itself that gets corrupted.
some other times seems the indexes where aswell. I don't have the whole log
at the moment but here are is what one PdxrBld log notes.
Table TOTAL MOVED - #records: 5909
Table Total Moved.db - Number of records 92 in block 1 does not match
index
Table TOTAL MOVED - #records: 6101
Index Total Moved.PX - Total blocks (3) greater than max blocks (2)
Index Total Moved.PX - Header size (2048) + data size (6144) does not
equal filesize (4096)
Difference: 4096 bytes
Index Total Moved.PX - Last block greater than total blocks
Index Total Moved.PX - Used blocks greater than total blocks
Used blocks = 3
Total blocks = 1
Index TOTAL MOVED.YG0 - Total blocks (3) greater than max blocks (2)
Index TOTAL MOVED.YG0 - Header size (2048) + data size (6144) does not
equal filesize (4096)
Difference: 4096 bytes
Index TOTAL MOVED.YG0 - Last block greater than total blocks
Index TOTAL MOVED.YG0 - Used blocks greater than total blocks
Used blocks = 3
Total blocks = 1
Index Total Moved.PX - Forward block pointer in block 1 is out of range
Table TOTAL MOVED - #records: 8476
Index Total Moved.PX - Total blocks (3) greater than max blocks (2)
Index Total Moved.PX - Pointer to last record (-1) in Block 3 is not
consistent with record size (21)
Index Total Moved.PX - Block pointers in block 1 do not match pointers
in block 3
Index Total Moved.PX - Empty block (3) in used block chain
> that said.. what kind of corruption?.. bad block pointer, or something
more
> sinister?.. have you rebuilt?.. have you exported to ascii and re-imported
to a
> clean table?..
One time, whe just decided to start off fresh, so I created a totally new
table and deleted the old one.
Liz
That link you found may be it or part of it or one of the issues
(primary key structure matters in the problem I'm vaguely
remembering). Certainly the 2048 block size with a single field key
shouldn't be the source of your corruption issues.
Liz
Steven Green
> Thanks Liz. I just left the default block size of 2048.
> The table's record count never exceeded 40,000
the "32k block" issue is not related to your problem.. it involves multi-field
keys, longints in the key, sec indexes, millions of records...
Steven Green
> I don't have the whole log at the moment but here are is what one PdxrBld log
> notes.
that overall pattern is easily seen when "opplocks" and "write behind" aren't
turned off, and/or LOCAL SHARE is FALSE..
Bill Todd
On Mon, 25 Aug 2003 08:58:05 +0200, "Dominic Dumée"
<dom...@psas.co.za> wrote:
>Now all I'm looking for an alternative that can handle the large number of
>records that app deals with in a networked environment without having to
>worry so much that the systems aren't configured perfectly. Is that too much
>to ask?
Not at all. All you have to do is convert tha app to use a database
server and run the server on a machine that runs Win2k or XP, has a
UPS and is not used for any other purpose. In this environment it is
extremely unlikely that the database server will crash and a
workstation crash cannot corrupt your database.
bcb
aren't
> turned off, and/or LOCAL SHARE is FALSE..
Thanks Steven. LocalShare is set to True, so it must be the "opplocks" and
"write behind" settings which must be disabled.
Thanks again and best regards to all.
bcb
I also think that the BDE settings are not the cause of the problem. I'll
experiment with disabling those windows file system settings and also close
the tables when not needed and schedule a weekly restart. All those things
put together should make for a very stable configuration.
Tuto
news:3F492B39...@paradoxcommunity.com...
Liz, thanks for your comments i'll implement it on my apps, Now i have a
question, as i see that you have many experience about it, i'd like to know
what is the best configuration on the BDE at side server and on the
Workstation, what i mean is which are the optimal values on the Palete
Configuration - System - Init on both sides (Server and WkSt). of the BDE
Administrator. ?
Thanks for your help.
Liz
Try this article (the server's kinda slow, so be patient) - it's
everything I could find on the subject. (NOTE: My recommendation is
that the server not even have the BDE on it, only workstations.)
http://www.thedbcommunity.com/interact/tt/ttbdeconfig.htm
Liz
Tuto
thedbcommunity, and i found tons of good information.
Best regards ;)
Chris Hedges
end that has just hit 7 million records in one of its tables!!!! thats right
7 million.
Its very stable but if one of the indexes goes out of date, boy it takes a
while to rebuild :) Normally we wouldn't allow our sites to grow their
tables this big, but this was required as they needed to do some statistical
reports on some historical data.
Most of out sites have well over 100,000 records in one or more of the main
system tables tho (500 sites).
Paradox is a capable database as long as its maintained correctly, and I've
never had any problems with it either (apart from one wierd update problem
I'm having at the moment) not bad for 8 years of usage tho....
"Bill Todd" <n...@no.com> wrote in message
news:bpkkkvskp7fnga3kg...@4ax.com...
Bill Todd
good luck with them. The keys to success are correct configuration, a
stable network and users who do not crash their workstations
frequently.
bcb
> end that has just hit 7 million records in one of its tables!!!! thats
right
> 7 million.
7mil :-D, that's good to know. The biggest I got to was 1.5mil. I seperate
data in yearly tables.
> Normally we wouldn't allow our sites to grow their
> tables this big, but this was required as they needed to do some
statistical
> reports on some historical data.
Same here, I need to collect that data for repotring.
> Paradox is a capable database as long as its maintained correctly, and
I've
> never had any problems with it either (apart from one wierd update problem
> I'm having at the moment) not bad for 8 years of usage tho....
Sorry for sounding like a broken record and/or nosy but what BDE and Windows
settings do you
have set? as you may have seen from the other posts in this topic I'm trying
to figure out a problem of my own and collected as much info as I can.
Bill already provided me with a lot of great info, so again I thank him.
What do you both recommend to use to test the network integrity, any tools,
utilities?
Thanks very much!
bcb
Well checking those 2 options in the Windows file system settings did not
help :-( The tables got corrupt in less than 2 weeks of 24/7 use. Another
thing I have to try yet is a daily restart, sometime at night when there is
much less traffic and no one might be around.But I still think there must be
something else that is wrong.
This link http://www.bdesupport.com/perform.htm mentions what are the
optimum BDE settings when accessing Paradox tables across a network. In my
situation that tables that are getting corrupted are not shared across the
LAN so I'm not sure how well they would effect those tables. At the moment
all settings except for MAXBUFSIZE are set to the recommended settings
mentioned in that link
For local tables, does setting the MAXBUFSIZE to 16384 really make such a
difference?
Because Iv'e looked through all the code over again and can't think of any
reason why my app would cause this. What I do know is that a infinite
recursion involving tables can cause corruption but there is no sign of that
here. Done nothing new there that I haven't done before, all other
applications do not have this problem.
I'll keep you posted.
"bcb" <noe...@sorry.com> wrote in message
news:3f4a...@newsgroups.borland.com...
Steven Green
> In my situation that tables that are getting corrupted are not shared across
> the
> LAN
then it must be something as simple as Local Share not being set to TRUE and/or
the opplocks/write-behind settings not being FALSE..
you are describing local tables not being flushed to disk correctly..
bcb
Opplocks/write-behind settings are set to FALSE. I always call
DBISaveChanges after each post, for local tables I've read that it has the
same effect as setting Local Share to true, both methods flush the data to
the disk. For tests sake I will set LocalShare to true and see if it helps.
"Steven Green" <gre...@diamondsg.com> wrote in message
news:3F6A29B2...@diamondsg.com...
Steven Green
> For tests sake I will set LocalShare to true and see if it helps.
all this, and you still haven't done that? <sigh>
bcb
> bcb wrote:
>
> > For tests sake I will set LocalShare to true and see if it helps.
>
> all this, and you still haven't done that? <sigh>
-------
I know what you mean but in this case LocalShare must be set to false. In
accordance with another BDE app that is running on the same computer.
In one location, after more than year of the app running with
LocalShare=false and DBISaveChanges being used instead, no corruptions at
all.
So at the time this problem started it hadn't entered my mind that using
that method was the problem since it has proven itself worthy someplace else
but after reading your last post I started to have some doubt.
You must be really tired from this subject and you seem like a person who
would not refuse to give a helping hand, I have collected a lot of info and
I don't think there is anything else I should know about pertaining to this
subject so call it case closed. I will continue further testing and see what
happens. I have learned a lot from you , so I thank you for sharing your
knowledge.
Steven Green
> I know what you mean but in this case LocalShare must be set to false. In
> accordance with another BDE app that is running on the same computer.
hypothetically, there is no such thing as a circumstance which requires FALSE..
> In one location, after more than year of the app running with LocalShare=false
> and DBISaveChanges being used instead, no corruptions at all.
merely setting FALSE doesn't guarantee problems.. it just increases the odds
dramatically..
> I will continue further testing and see what happens. I have learned a lot
> from you , so I thank you for sharing your knowledge.
no preblem.. don't forget to let us know the end result..
bcb
FALSE..
interested why Local Share is set to false.
Well I'll try to explain what the other app does, it's pretty old. In my
knowledge It just compiles and categorizes many tables from various sources
into a easy to work with format. Now some PC on the network wants to get all
the data from that PC onto their own machine by just copying the table files
over that is what I think starts the trouble, it can sometimes cause windows
file sharing errors, I think the tables aren't released by the BDE? But if
someone tries using the Windows Explorer to copy the table files it always
seems to work no matter what tables are open by the BDE, even if
LocalShare=true.
I'm busy with the some othe part of my own project to really concentrate on
these few problem spots they aren't currently so severe but are
distractions, it takes a few minutes to fix those tables with a rebuild,
apparently AFAIK no data is being lost, also all of the data is somewhere
laying unprocessed on another PC just in case. In the near future I plan to
re-write and integrate the features of that application. I also will install
a logger on the troublesome PC to see what exactly is going on(e.g. too many
restarts) when I'm not there , with the permission of the boss of course.
Some folks either exaggerate problems,minimize them or don't know what's
going on at all.
Anyhow that should be it, I honestly don't want Steven and Bill to give more
attention to this problem.They've done enough. This whole topic is archived
with Tamaracka and Google groups so it may help someone someday.
> merely setting FALSE doesn't guarantee problems.. it just increases the
odds
> dramatically..
You're right.
> don't forget to let us know the end result..
I will.
Thanks very much for all the help :-D
Leslie Milburn
"bcb" <noe...@sorry.com> wrote in message
news:3f6b...@newsgroups.borland.com...
>
> Well I'll try to explain what the other app does, it's pretty old. In my
> knowledge It just compiles and categorizes many tables from various
sources
> into a easy to work with format. Now some PC on the network wants to get
all
> the data from that PC onto their own machine by just copying the
> table files......
This could be your corruption problem !!!
I have found that even having explorer open and highlighting a table index
can cause problems because explorer tries to read the file properties. If
this happens at an inappropriate moment (ie a workstation is trying to save
data) the index has been known to get corrupted.
Even if this does not prove to be the problem, I strongly suggest it is bad
practice to allow the tables to be copied potentially whilst the database is
in use. Even trying to run a backup whilst the tables are in use *fails*
99.9% of the time.
Leslie.
Steven Green
> It just compiles and categorizes many tables from various sources into a easy
> to work with format. Now some PC on the network wants to get all the data from
> that PC onto their own machine by just copying the table files over that is
> what I think starts the trouble, it can sometimes cause windows file sharing
> errors, I think the tables aren't released by the BDE?
the errors are because Local Share is FALSE, and files aren't flushed..
bcb
> This could be your corruption problem !!!
>
> I have found that even having explorer open and highlighting a table index
> can cause problems because explorer tries to read the file properties. If
> this happens at an inappropriate moment (ie a workstation is trying to
save
> data) the index has been known to get corrupted.
>
> Even if this does not prove to be the problem, I strongly suggest it is
bad
> practice to allow the tables to be copied potentially whilst the database
is
> in use. Even trying to run a backup whilst the tables are in use *fails*
> 99.9% of the time.
Thanks for your insights and already understand what you're saying but those
tables that are getting corrupted aren't touched by anyone across the
network, not copied and not shared, the opposite is happening, where you
would think the files would get corrupted because someone is trying to
access them are not getting corrupted. I also mentioned that I do plan on
re-writing the application that causes me to set Local Share to false. In
the mean time placing a logger on a few machines would give me more insight
on what might be happening.
bcb
> bcb wrote:
>
> > It just compiles and categorizes many tables from various sources into a
easy
> > to work with format. Now some PC on the network wants to get all the
data from
> > that PC onto their own machine by just copying the table files over that
is
> > what I think starts the trouble, it can sometimes cause windows file
sharing
> > errors, I think the tables aren't released by the BDE?
>
> the errors are because Local Share is FALSE, and files aren't flushed..
The file sharing message only shows when Local Share is true. I will disable
the other app temporarily set LocalShare to True and see how well my app
works. And again I do use DBISaveChanges(after posts and deletes) which for
a local app should be the same as LocalShare set to true, so data should be
flushed, and I've changed that all of tables that aren't needed are closed.
I don't use TQueries but TTables with Paradox tables.
Folks thanks for your insights but I don't think anyone can help from here.
You've already helped a lot so far and I can't repay you enough. Just go and
enjoy the weekend :-) unless this is what you like do in your spare time,
hang out here.
Steven Green
> The file sharing message only shows when Local Share is true.
here's what will happen in a normal situation.. sounds like the other app ran
into this wall, and broke the rules to try and avoid it..
if you get a "sharing violation" in any context, that means an app and/or the OS
has the files locked.. maybe you (or the other app) don't want the files to be
locked.. maybe you (or the other app) didn't think the files *were* locked.. but
they are.. that's what the error message means..
if they're not supposed to be locked, find out why they are.. don't change to
FALSE, and put the data at risk, instead of finding the flaw and correcting it..
I realize that the original problem is the logic used by the other app.. but
it's forcing you to work with that logic.. and that logic is BAD.. and you're
getting all of the problems because of it.. even if you aren't the cause..
> Just go and enjoy the weekend :-)
and where's the sport in that? <g>
bcb
> > Just go and enjoy the weekend :-)
>
> and where's the sport in that? <g>
Well, the weekend if almost over and it's been like any other day for me,
spent most of the time in front of the PC, bust a tad less than I normally
do the weather was much to good to stay inside. I must get one those smart
displays ;-)