|
Home > Archive > Programming with dBASE > March 2006 > Couldn't perform the edit because...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Couldn't perform the edit because...
|
|
|
| Hi All,
Awhile ago, I read messages in a old dbase newsgroup about the same BDE error. I have now encountered the same error:
"Couldn't perform the edit because another user changed the record."
This error occurs only when traversing and editing a table (2800 rows, approx.) and using cacheUpdates. Even if a use
....applyupdates() every 1 row -or any number of rows less than 1000- it' ll crash at or after approx. 2100 edited rows.
I'm stumped.
Thanks for any input.
Mark
| |
| *Lysander* 2006-03-05, 8:27 pm |
| mark schrieb:
> This error occurs only when traversing and editing a table (2800 rows, approx.) and using cacheUpdates. Even if a use
> ...applyupdates() every 1 row -or any number of rows less than 1000- it' ll crash at or after approx. 2100 edited rows.
Cached updates are VERY bad to use in modern systems.
It does not work reliably.
That's because a big deal of local cacheing is done by the
network-redirector clients of Windows to provide faster network
access and less traffic.
Unfortunately, those more new systems of traffic management are not
compliant with some old/older techniques of existing software, like
for example the BDE.
Borland EXPLICITELY recommends to set all BDE-clients to "LOCAL
SHARE = TRUE" and also to turn off all other kinds of local cacheing.
ciao,
André
| |
|
| André,
Thanks for your reply.
Unfortunately, I am not going to rewrite the part of the application (several modules and several program) that uses
cacheupdates.
I agree with you, cacheupdates is not a failsafe feature of the BDE and it certainly has given me few headaches over
years.
I have also noticed the problem only occurs with tables that have a memo field.
I solved the problem by using an sql statement that excludes the memo field.
Memo fields have been a nightmare for dbase, for many years, going back to db5 dos format.
Thanks
Mark
"*Lysander*" <nobody@nowhere.com> wrote in message news:rgbgfpsPGHA.1148@news-server...
> mark schrieb:
>
>
> Cached updates are VERY bad to use in modern systems.
> It does not work reliably.
> That's because a big deal of local cacheing is done by the network-redirector clients of Windows to provide faster
> network access and less traffic.
> Unfortunately, those more new systems of traffic management are not compliant with some old/older techniques of
> existing software, like for example the BDE.
>
> Borland EXPLICITELY recommends to set all BDE-clients to "LOCAL SHARE = TRUE" and also to turn off all other kinds of
> local cacheing.
>
> ciao,
> André
| |
| *Lysander* 2006-03-05, 8:27 pm |
| mark schrieb:
> Memo fields have been a nightmare for dbase, for many years, going back to db5 dos format.
completely wrong, and I would suggest that you do not post something
like this, unless you are sure that the problems are indeed based on
the memo-fields as such and not just on the way you are using them.
Strange enough, messages keep popping up in here, where people tell
that memo-fields are a problem, usually people add "in dbase".
That's just not true, because a lot of people are using a lot of
memos withOUT any problems at all.
People who have problems with memos in dBase will most certainly
also have problems with memos in other languages/formats.
The guidelines for using memos are clear and should be well known to
everybody here, thanks also to people like Ken Mayer and others who
are publishing general informations.
You can tell "no, for me that's too complicated to go the
recommended way", but then you should not complain that you
experience problems.
In your special case, did you try to increase the "BLOBs to cache"
value in the BDE-settings? It COULD help, although I am not too sure
about this.
When using CachedUpdates, you can not be too sure about anything in
a modern network with modern clients.
ciao,
André
| |
|
| André,
Don't get me wrong and don't be too defensive.
Let me re-phrase my statement and attempt to make it a little clearer .
Memo fields have been a problem for myself, partly because I do not know how to safely use them -despite a number of
work-arounds posted in this newsgroup. To date, I have never seen official guidelines for the use of memo fields -When,
where and how to use them or not use them.
This problem goes back all the way to borland -I can't remember if ashton tate had this problem. This is not a criticism
of any products or persons, but simply a statement of facts. If I, or other users, experience a common problem that
remains unresolved -for whatever reason- it is fair to state "Memo fields have been a nightmare for dbase..." because I
am using dBase and I experience a lot of problems with dbase memo fields in dbf tables using BORLAND DATABASE ENGINE.
I also agree with you that my statement might have wrongly implied that the problem is related to dbase ONLY. This is
not true. I can only assume that it is more of a BDE problem rather than a dbase problem.
But, there again, memo fields have caused me headaches when using dbase upto and including 2.6.
For instance if a memo field is datalinked to a editor object I have to undo the link before I save or create a rowset.
This is the only way I can use to avoid the ugly error "Too many blobs". You're entitled to believe that many users are
using memo fields without any problems, just as I am entitled to believe the opposite. However, previous newsgroups
reported quite few memo fields problems -mainly "too many blobs and corrupt memo BLOBs errors". Checkout google.
I also agree with you about BDE and modern network. Modern network processes, design, etc. have improved whilst
borland's BDE stagnated.
Au revoir et merci
Mark
"*Lysander*" <nobody@nowhere.com> wrote in message news:v3iv8UtPGHA.2016@news-server...
> mark schrieb:
>
>
> completely wrong, and I would suggest that you do not post something like this, unless you are sure that the problems
> are indeed based on the memo-fields as such and not just on the way you are using them.
>
> Strange enough, messages keep popping up in here, where people tell that memo-fields are a problem, usually people add
> "in dbase". That's just not true, because a lot of people are using a lot of memos withOUT any problems at all.
>
> People who have problems with memos in dBase will most certainly also have problems with memos in other
> languages/formats.
>
> The guidelines for using memos are clear and should be well known to everybody here, thanks also to people like Ken
> Mayer and others who are publishing general informations.
>
> You can tell "no, for me that's too complicated to go the recommended way", but then you should not complain that you
> experience problems.
>
> In your special case, did you try to increase the "BLOBs to cache" value in the BDE-settings? It COULD help, although
> I am not too sure about this.
> When using CachedUpdates, you can not be too sure about anything in a modern network with modern clients.
>
> ciao,
> André
| |
| *Lysander* 2006-03-05, 8:27 pm |
| In article <A12tCwtPGHA.592@news-server>, hicom05@btinternet.com says...
> Don't get me wrong and don't be too defensive.
sorry if I was sounding aggressive; it was not meant so.
set the BLOBs to cache higher.
Standard 64 is from the time when RAM was more sparse.
A German user - Andreas Beckhaus - recommends even something as 20.000=20
as a safe setting.
If your users need to ACTIVELY scroll down 20.000 records, and then up=20
20.001 again, then you definitely should change the design.
Check, if you definitely on all clients have LOCALSHARE turned off=20
(false).
And then, most important of all, keep the memo-fields separate from the=20
other fields in a separate table; link this table to the "main" table=20
via primary key.
I have maybe as many as 200 or 300 memofields throughout my database,=20
didn't count them exactly. Never a problem in 7 years.
ciao,
Andr=E9
| |
|
| Hi Andre,
when you say "set the BLOBs..." do you mean the maxbufsize?
Mark
| |
| *Lysander* 2006-03-05, 8:27 pm |
| In article <LEohDQ3PGHA.2068@news-server>, hicom05@btinternet.com=20
says...
> Hi Andre,
>=20
> when you say "set the BLOBs..." do you mean the maxbufsize?
No, I think I was talking Bullshit here.
The BLOBs to cache only exist for ODBC-drivers, so it will not help you=20
with problems for native tables.
Sorry.
Then I can indeed only recommend the other things, especially keeping=20
memos in separate tables and linking them with primary keys.
ciao,
Andr=E9
| |
|
| Hi Andre,
Does this mean that keeping memo fields within the same table used for storing other types of data might cause a
problem?
Thanks
Mark
"*Lysander*" <noone@nowhere.com> wrote in message news:MPG. 1e73acaadc80d61f9896
9a@news.dbase.com...
In article <LEohDQ3PGHA.2068@news-server>, hicom05@btinternet.com
says...
> Hi Andre,
>
> when you say "set the BLOBs..." do you mean the maxbufsize?
No, I think I was talking Bullshit here.
The BLOBs to cache only exist for ODBC-drivers, so it will not help you
with problems for native tables.
Sorry.
Then I can indeed only recommend the other things, especially keeping
memos in separate tables and linking them with primary keys.
ciao,
André
| |
| *Lysander* 2006-03-06, 7:23 am |
| mark schrieb:
> Hi Andre,
>
> Does this mean that keeping memo fields within the same table used for storing other types of data might cause a
> problem?
Definitely! Causes the biggest problems possible with memo-fields.
Problems are getting bigger, when other fields are frequently edited.
Hope this helps for future design.
ciao,
André
| |
|
| André,
Thank you very much.
As I said previously, there was no guidelines in all dbase user guides with reference to memo fields -in terms of design
and implementation.
There isn't a hope in hell in changing the table structure because there are far too many programs with my app that need
updating, if I change the structure.
Thanks
Mark
"*Lysander*" <nobody@nowhere.com> wrote in message news:YH%23RgOQQGHA.2320@news-server...
> mark schrieb:
>
> Definitely! Causes the biggest problems possible with memo-fields.
> Problems are getting bigger, when other fields are frequently edited.
>
> Hope this helps for future design.
>
> ciao,
> André
| |
| *Lysander* 2006-03-09, 9:23 am |
| mark schrieb:
> There isn't a hope in hell in changing the table structure because there are far too many programs with my app that need
> updating, if I change the structure.
Unfortunately, this is very often the case.
I don't know about written documentation, but it was mentioned in
these newsgroups often enough.
I have myself just been lucky, I guess.
I was working very intensely with Crystal Reports already back in
times of VdB 5.5.
It was just not possible to have stable reports with memo-fields
unless they had a primary key.
good luck.
ciao,
André
| |
|
| I never seen it on the NG, although I reported numerous problems linked to memos, and the only half-backed solution that
I opted for was to remove the datalink from editor objects when saving or appending to a rowset.
We live and learn.
Thanks
Mark
"*Lysander*" <nobody@nowhere.com> wrote in message news:U3d%232z4QGHA.1152@news-server...
> mark schrieb:
>
>
> Unfortunately, this is very often the case.
> I don't know about written documentation, but it was mentioned in these newsgroups often enough.
>
> I have myself just been lucky, I guess.
> I was working very intensely with Crystal Reports already back in times of VdB 5.5.
>
> It was just not possible to have stable reports with memo-fields unless they had a primary key.
>
> good luck.
>
> ciao,
> André
|
|
|
|
|