Versions of Express and index issue with Dclip1

[omni]

Roger,

This has been on a couple of other threads but I thought in this case it is best to open new.

Our users are currently on 263. We are changing to use dbesys and dclip1.lib. I have a test set up on their system with the new menu.
They are currently on the old one, not with dclip1.lib or dbesys. This is an issue with dclip1.lib. This customer is on 2.0, but that has not made any difference that we have seen

To give a little background, all our major databases and indexes were originally created used old foxpro 2.6. That goes back a lot of years and we have maintained that, mostly due to those being able to be opened in excel.

IN our app, there are some programs that create or recreate indexes. Those are the files that cause problems. If we open a menu option that has one of those files and indexes, when exiting the menu option, and close all is done, there is either an operating system error, or in some cases it just locks up and will not do anything. File is left open at that time, failing to close.

If we open the same menu option using their current live menu on the same server there is no issue. We tested this on a menu option yesterday a dozen times, back and forth. Reindexing using the old (their current version) does not help. Reindexing using dclip1.dll also does not help. the only option is to recreate the indexes using the dclip1.lib , or send the original file and index created by foxpro and import and reindex using dclip1.dll (which is what we have been doing).
Out of 200+ files with indexes, this involves about a dozen files.

As we update the users we can send them empty replacement files, which import and reindex as part of the update. Just wanted this to be known, and also asking if there is an alternative.

Another part of this that we found is in these cases where there is an operating system error and it will not close a file, we cannot get out using the error routine. Even the QUIT fails, for the same reason. It cannot close the file.

Sorry for the length of this. Hope it is understandable...I was trying to give as much detail as I could

**************************************************
(here are the new settings we are using in DBESYS)

DbeSetDefault('FOXCDX')

DbeInfo( COMPONENT_DATA, FOXDBE_CREATE_2X, .F. )
DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE , FOXDBE_LOCKMODE_VISUAL )

**************************************************


Fred
Omni

[rdonnay]

It sounds to me like you should be able to isolate this.

You say that you have a program that corrupts the databases.
You say that you have another program that does not corrupt the databases.

Am I correct about this?

If I am, then it stands to reason that you just need to compare code between the two programs and find how loading the FOXDBE and configuring it would be different.

You have the source for DCLIP1.DLL. The DBEs are loaded in the DC_LoadRdds() function in _DCINIT.PRG.

[omni]

Same exact program and menu, same server. Only difference is that one uses dclip1.dll and dbesys, and one does not. Run from different folders but the data is in the data folder.
Not a program comparison issue, only how the system is reading or not reading the same dbf and cdx file. Xdot also locks up on the file. and must use task manager to close it.

We just did an update at another site and the same thing is happening. There are random files that are causing operating system errors that were not prior to updating them with the new method for loading fox and indexing.

I could actually show you if you have time what it is doing. Maybe there are commands that can be tried in dbesys to make it work without this locking up.

Fred

[Auge_Ohr]

hi,

it seem me you have mixed DBF and/or different DBE Setting.
use DC_DbeType( cDbf ) to test your DBF Files.


if you have a "Net_Use" Function to open DBF try to enhance it this way

Code: Select all

Function Net_Use(cDBF)
LOCAL lOk := .F. 
LOCAL aDBE := {}
LOCAL aInfo

   AADD(aDBE, DbeInfo( COMPONENT_DATA,  DBE_NAME ) )
   AADD(aDBE, DbeInfo( COMPONENT_ORDER, DBE_NAME ) )
   AADD(aDBE, DbeInfo( COMPONENT_DATA, FOXDBE_CREATE_2X) )
   AADD(aDBE, DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE ) )
   AADD(aDBE, DbeInfo( COMPONENT_DATA,DBE_VERSION) )

   ...
   aInfo := DC_DbeType( cDbf )
   DO CASE
      CASE aInfo[1] = 131 // "FoxPro/dBASEIII/Ads/Clipper with memo"
           IF aInfo[4] = "NTX" .AND. aDBE[2] = "NTXDBE"  
              lOk := .T. 
           ENDIF                          
      CASE aInfo[1] = 48  // "Visual Foxpro/Ads", "FOXCDX/ADSDBE"
           IF aInfo[4] = "CDX" .AND. aDBE[2] = "CDXDBE" .AND. aDBE[3] = "N"  .AND. aDBE[4] = 1003
              lOk := .T. 
           ENDIF                          
      CASE aInfo[1] = 245 // "Foxpro 2.x/Ads with memo"
           IF aInfo[4] = "CDX" .AND. aDBE[2] = "CDXDBE" .AND. aDBE[3] = "J"  
              IF aDBE[4] = 1002 .or aDBE[4] = 1004
                 lOk := .T. 
              ENDIF                          
           ENDIF                          
   ENDCASE

   IF lOK
      bSaveErrorBlock := ERRORBLOCK( { | e | BREAK( e ) } )
      BEGIN SEQUENCE
         USE (cdbf) VIA aDBE[2]
         lOK := .NOT. NETERR()
          ...
      RECOVER USING oERROR
         lOK := .F.
         nError := oError:osCode
         ...
      ENDSEQUENCE
      ERRORBLOCK(bSaveErrorBlock)
   ENDIF 

RETURN lOK