corruption detected ; cl53b-dbfcdx-bl3.3 
Author Message
 corruption detected ; cl53b-dbfcdx-bl3.3

cl53b
dbfcdx
bl3.3
funcky 2.5
Win ME, peer-to-peer

I was having some "corruption detected" problems with a client of
mine, since switching to 5.3/dbfcdx.

- The occured unpredictably occur at fixed points of the code which
seem harmless and go well 9999 / 10000 times.
- They occur after dbcommit / dbunlock / dbseek / dborderinfo or at
memoedit.
- They occur at the machine the files are on, but also on
"workstations"
- only two of the databases seem to be affected

I didn't really get in to it yet, but some days ago there were
suddenly big problems like incomplete records being created (some
fields empty) and the corruption errors were accompanied by read
errors. These problems disappeared after "remaking" the database, a
function of my program which makes a temp dbf, appends from the chosen
dbf and renames the temp to the original dbf name.

I have been going through this newsgroup with google search and found
tons of information and suggestions (like upgrading blinker). Problem
is that the error maybe so rare again from now it is very hard to
evaluate the result of my actions.

Because I am wondering if I am doing some fundamentally wrong things I
would l like some advice on my methods.
- I was using the stack 10000 command at linking, maybe set procedure
depth is better? (link file see below)
-I always flock in stead of rlock my files when writing to databases (
is dbcommit necessary after rlock? and after dbappend?)
-i have a standard unlock function in which there is first dbcomit and
then dbunlock
-sometimes i choose not to commit after writing "non essential" info
(f.e. date/time a customer was selected last time) in order not to
slow down the program unnecessary - but the error also appears on a
database I ALWAYS commit to)
- I read somewhere you should put records in there natural order
before changing index-key fields, is this true? I never had problems
like these in clipper 5.01/DBFNTX

thnx, Hans

=======================================
link file:
=======================================

BLINKER EXECUTABLE EXTENDED 4096
BLINKER EXECUTABLE NODELETE
BLINKER EXECUTABLE CLIPPER //F:65
blinker incremental OFF
output c:\temp\menu.exe

STACK 10000

search c:\dos\clipper\blinker3\lib\blxclp53.lib

file ..... (my prg files)

allocate c:\dos\clipper\cl53\lib\extend.lib
allocate DBFCDX, _DBFCDX

allocate c:\dos\clipper\abee\lib\clip53\pscript.lib

allocate c:\dos\clipper\funcky25\lib\funcky2x.lib
allocate c:\dos\clipper\funcky25\lib\funckyvm.lib
allocate c:\dos\clipper\funcky25\lib\funcky53.lib

allocate c:\dos\clipper\catools\ctp.lib

allocate c:\dos\clipper\oslib\oslib.lib
allocate c:\dos\clipper\oslib\cpmi.lib

file __wait_b.job

====================================



Sun, 01 Aug 2004 03:09:28 GMT  
 corruption detected ; cl53b-dbfcdx-bl3.3
Comments in-line...


Quote:
> cl53b
> dbfcdx
> bl3.3
> funcky 2.5
> Win ME, peer-to-peer

> I was having some "corruption detected" problems with a client of
> mine, since switching to 5.3/dbfcdx.

How long ago did you switch?  When did the problems begin?

Quote:
> - The occured unpredictably occur at fixed points of the code which
> seem harmless and go well 9999 / 10000 times.
> - They occur after dbcommit / dbunlock / dbseek / dborderinfo or at
> memoedit.
> - They occur at the machine the files are on, but also on
> "workstations"
> - only two of the databases seem to be affected

Review the code that writes to these two databases.  I find that 95% of the
time, it's my fault.

Quote:

> I didn't really get in to it yet, but some days ago there were
> suddenly big problems like incomplete records being created (some
> fields empty) and the corruption errors were accompanied by read
> errors. These problems disappeared after "remaking" the database, a
> function of my program which makes a temp dbf, appends from the chosen
> dbf and renames the temp to the original dbf name.

Check the integrity of the server's drive (scandisk, whatever).  Make sure
all network connections are snug and not intermittent.

Quote:
> I have been going through this newsgroup with google search and found
> tons of information and suggestions (like upgrading blinker). Problem
> is that the error maybe so rare again from now it is very hard to
> evaluate the result of my actions.

I hate that!

Quote:
> Because I am wondering if I am doing some fundamentally wrong things I
> would l like some advice on my methods.
> - I was using the stack 10000 command at linking, maybe set procedure
> depth is better? (link file see below)
> -I always flock in stead of rlock my files when writing to databases (
> is dbcommit necessary after rlock? and after dbappend?)

Don't you find it difficult using flock() in a multiuser environment?  If
you are doing updates to many records at once, flock() is prudent.  If you
are just updating a single record, rlock() is more appropriate.  In a
network environment, a commit after each write is a good practice.  The
usual steps are append or lock, write, commit, unlock.

Quote:
> -i have a standard unlock function in which there is first dbcomit and
> then dbunlock

Me too.

Quote:
> -sometimes i choose not to commit after writing "non essential" info
> (f.e. date/time a customer was selected last time) in order not to
> slow down the program unnecessary - but the error also appears on a
> database I ALWAYS commit to)

If you're going to do it, you might as well do it everywhere.  The only time
I don't commit after each write is when I have exclusive use of the database
(flock() doesn't count!).  Then I commit just before I close it.  When doing
mass updates on a file I have exclusive use of, it's MUCH faster.

Quote:
> - I read somewhere you should put records in there natural order
> before changing index-key fields, is this true? I never had problems
> like these in clipper 5.01/DBFNTX

That is not necessary when updating a single record.  If you are skipping
through a database when doing so, then you most definitely need to be
skipping through in an order that won't be affected by your changes.

Quote:
> thnx, Hans

> =======================================
> link file:
> =======================================

[SNIP]

I'll let someone else analyze the link script.  There are others here with
more experience in that area.

--
Ray Marron



Sun, 01 Aug 2004 04:52:51 GMT  
 corruption detected ; cl53b-dbfcdx-bl3.3



Quote:
> cl53b
> dbfcdx
> bl3.3
> funcky 2.5
> Win ME, peer-to-peer

> I was having some "corruption detected" problems with a client of
> mine, since switching to 5.3/dbfcdx.

> - The occured unpredictably occur at fixed points of the code which
> seem harmless and go well 9999 / 10000 times.
> - They occur after dbcommit / dbunlock / dbseek / dborderinfo or at
> memoedit.
> - They occur at the machine the files are on, but also on
> "workstations"
> - only two of the databases seem to be affected

Hi Hans,

In Clipper 5.3 is bug ( in 5.2, 5.01 No!). He is in DBFNTX and DBFCDX rdd.
Pleas see your sorce code, and find instruction which writes value when DBF
is in Eof() state.
Example :

dbGoBottom()
dbSkip( 1)
? Eof() // .t.
If Rlock() // .t.
        dbDelete() // in 5.3 don't can write when dbf is in Eof() !!!
        *-- or Field->someName := someValue etc.
End
... some instructions
// now dbGoTop(), dbSkip( n) etc. (often in another function !!! ) show
error "corruption detected"
// in clipper 5.2, 5.01 all is ok.

Sorry for my bad english.
Regards,
Marek Horodyski



Sun, 01 Aug 2004 17:55:57 GMT  
 corruption detected ; cl53b-dbfcdx-bl3.3
I am still using Clipper 5.2, but I do use the Comix DBFCDX database driver
on which I think the Clipper 5.3 DBFCDX is based.  The default action for
Comix is that "Comix does not force DOS to physically write to disk when a
COMMIT is done".  This caused me some grief for a while until I discovered
this rather fundamental change to the action associated with a command.  In
Comix you can force it to behave properly with a call to cmxSys(1002, .T.).
Since then I have been most impressed with the reliability and performance
of their DBFCDX database driver.

I do not know what the default behaviour is in Clipper 5.3 DBFCDX, or
whether you can change it, but this may have some relevance to your problem.

John Davis.


Quote:
> cl53b
> dbfcdx
> bl3.3
> funcky 2.5
> Win ME, peer-to-peer

> I was having some "corruption detected" problems with a client of
> mine, since switching to 5.3/dbfcdx.

> - The occured unpredictably occur at fixed points of the code which
> seem harmless and go well 9999 / 10000 times.
> - They occur after dbcommit / dbunlock / dbseek / dborderinfo or at
> memoedit.
> - They occur at the machine the files are on, but also on
> "workstations"
> - only two of the databases seem to be affected

> I didn't really get in to it yet, but some days ago there were
> suddenly big problems like incomplete records being created (some
> fields empty) and the corruption errors were accompanied by read
> errors. These problems disappeared after "remaking" the database, a
> function of my program which makes a temp dbf, appends from the chosen
> dbf and renames the temp to the original dbf name.

> I have been going through this newsgroup with google search and found
> tons of information and suggestions (like upgrading blinker). Problem
> is that the error maybe so rare again from now it is very hard to
> evaluate the result of my actions.

> Because I am wondering if I am doing some fundamentally wrong things I
> would l like some advice on my methods.
> - I was using the stack 10000 command at linking, maybe set procedure
> depth is better? (link file see below)
> -I always flock in stead of rlock my files when writing to databases (
> is dbcommit necessary after rlock? and after dbappend?)
> -i have a standard unlock function in which there is first dbcomit and
> then dbunlock
> -sometimes i choose not to commit after writing "non essential" info
> (f.e. date/time a customer was selected last time) in order not to
> slow down the program unnecessary - but the error also appears on a
> database I ALWAYS commit to)
> - I read somewhere you should put records in there natural order
> before changing index-key fields, is this true? I never had problems
> like these in clipper 5.01/DBFNTX

> thnx, Hans

> =======================================
> link file:
> =======================================

> BLINKER EXECUTABLE EXTENDED 4096
> BLINKER EXECUTABLE NODELETE
> BLINKER EXECUTABLE CLIPPER file://F:65
> blinker incremental OFF
> output c:\temp\menu.exe

> STACK 10000

> search c:\dos\clipper\blinker3\lib\blxclp53.lib

> file ..... (my prg files)

> allocate c:\dos\clipper\cl53\lib\extend.lib
> allocate DBFCDX, _DBFCDX

> allocate c:\dos\clipper\abee\lib\clip53\pscript.lib

> allocate c:\dos\clipper\funcky25\lib\funcky2x.lib
> allocate c:\dos\clipper\funcky25\lib\funckyvm.lib
> allocate c:\dos\clipper\funcky25\lib\funcky53.lib

> allocate c:\dos\clipper\catools\ctp.lib

> allocate c:\dos\clipper\oslib\oslib.lib
> allocate c:\dos\clipper\oslib\cpmi.lib

> file __wait_b.job

> ====================================



Sun, 01 Aug 2004 18:31:06 GMT  
 corruption detected ; cl53b-dbfcdx-bl3.3
On Wed, 13 Feb 2002 10:31:06 +0000 (UTC), "John Davis"

Quote:

>Comix you can force it to behave properly with a call to cmxSys(1002, .T.).
>Since then I have been most impressed with the reliability and performance
>of their DBFCDX database driver.

>I do not know what the default behaviour is in Clipper 5.3 DBFCDX, or
>whether you can change it, but this may have some relevance to your problem.

>John Davis.

I had found the cmxSys(1002, .T.) 'solution' while seraching with
Google. In cl 5.3 this command is not recognized. So I wonder how I
can find out if a real commit is being issued and how to make certain
there is.

Hans



Sun, 01 Aug 2004 19:04:29 GMT  
 corruption detected ; cl53b-dbfcdx-bl3.3
On Wed, 13 Feb 2002 10:55:57 +0100, "Marek Horodyski"

Quote:

>In Clipper 5.3 is bug ( in 5.2, 5.01 No!). He is in DBFNTX and DBFCDX rdd.
>Pleas see your sorce code, and find instruction which writes value when DBF
>is in Eof() state.

I had concidered your findings with database corruptions
 Writing in an eof state is out of the question as far as I can see.
Also if I code-force an end of file situation just before the point an
error sometimes occurs there is no error.

&& - forcing an end of file here = no error
h_lock(6)
pat_kaar->(dbappend())
pat_kaar->datum_in           := dedatum
pat_kaar->dier_nr            := fDier()  && function
                                                       && only stores
                                 && /- returns
                                                       &&  float
pat_kaar->opmerking          := cRegel
pat_kaar->tijd                       := time()
pat_kaar->gebruiker          := aUser()[5] && function
                                        && just stores -/ returns
                                        && array, 5th el = char
h_unlock(6)        ------>error see in function

*====================================
function h_unlock(iBes,lCommit)
local cAlias      := STA(iBes)  && function just returns
                                             && alias name from array
If lCommit == nil .or. lCommit
        &cAlias->(dbcommit())                             ----->error
endif
&cAlias->(dbunlock())
unflag(iBes)  && setting a semafore.dbf so that
                    && a write tot the database has been
                    && legally concluded
SetDbfTime(cAlias) && setting dbf/fpt/cdx date time for
                               && synchronisation checking
return nil
*=========================================================
function h_lock(iBes)
local iNu
local lRet := .F.
dbselectarea(iBes)
Flag(iBes)
if ! flock()
     iNu   := seconds()
     do while inkey() <> ESC
        fout_box("Netwerk bezet " + cFileNaam(,iBes) + " " + ;
                      str( TimeDiff(iNu,seconds() ),2,0) ,999 )
        if flock()
                lRet := .T.
                exit
        endif
     enddo
else
     lRet  := .T.
endif
return lRet

Hans



Sun, 01 Aug 2004 19:25:36 GMT  
 corruption detected ; cl53b-dbfcdx-bl3.3
On Tue, 12 Feb 2002 13:52:51 -0700, "Ray Marron"

Quote:

>How long ago did you switch?  When did the problems begin?

The first version with Cl53/DBFCDX dates from jun-2000
The first corruption detected proudly gave birth on 9-aug 2000 and
reoccured on 30 occasions with one particular client.
(A client I have full network access to)

Hans



Sun, 01 Aug 2004 19:44:38 GMT  
 corruption detected ; cl53b-dbfcdx-bl3.3



Quote:
> On Wed, 13 Feb 2002 10:55:57 +0100, "Marek Horodyski"


[...]
pleas try :

Quote:
> *====================================
> function h_unlock(iBes,lCommit)
> local cAlias      := STA(iBes)  && function just returns
>                                              && alias name from array
> If lCommit == nil .or. lCommit

            If &cAlias->( Eof())
               Alert( 'Oh mammamija - ples see in ' + &cAlias)
            End

Quote:
>         &cAlias->(dbcommit())                             ----->error
> endif

I have experience with this error.

Marek Horodyski



Sun, 01 Aug 2004 21:39:15 GMT  
 corruption detected ; cl53b-dbfcdx-bl3.3

Quote:
> So I wonder how I can find out if a real commit
> is being issued and how to make certain there is.

AFAIK, you can't.  I think the best you can do (which should be pretty good
in a peer-to-peer environment) is to disable write-behind caching on all
drives.  How to do this varies by OS (and I have never used the dreaded
WinME in production) so you can probably find out how on Microsoft's
website.

--
Ray Marron



Sun, 01 Aug 2004 22:21:56 GMT  
 corruption detected ; cl53b-dbfcdx-bl3.3
On Wed, 13 Feb 2002 14:39:15 +0100, "Marek Horodyski"

Quote:

>            If &cAlias->( Eof())
>               Alert( 'Oh mammamija - ples see in ' + &cAlias)
>            End

But how can my database be in eof() when I just did an append and
filled some fields???????????????????


Sun, 01 Aug 2004 22:44:24 GMT  
 corruption detected ; cl53b-dbfcdx-bl3.3



Quote:
> On Wed, 13 Feb 2002 14:39:15 +0100, "Marek Horodyski"

> >            If &cAlias->( Eof())
> >               Alert( 'Oh mammamija - ples see in ' + &cAlias)
> >            End

> But how can my database be in eof() when I just did an append and
> filled some fields???????????????????

Maby you have reverse relations ? It is only suppose.

Regards,
Marek Horodyski



Mon, 02 Aug 2004 00:58:05 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. Corruption detected (DBFCDX)

2. Error DBFCDX/8006 Corruption detected

3. ERROR DBFCDX/1012 CORRUPTION DETECTED

4. Corruption Detected : DBFCDX/1012

5. DBFNTX / 1210 Corruption Detected .... Revisited

6. Corruption detected

7. DBF File - Corruption detected

8. Urgent Help !! DBFNTX/1012 Corruption detected:

9. CORRUPTION DETECTED ERROR

10. Error : DBFNTX/1210 Corruption Detected

11. Corruption Detected Error on NTX with 2 versions of Clipper 5.2

12. DBFNTX/1210 Corruption Detected error

 

 
Powered by phpBB® Forum Software