Reindex your FOXCDX database when switching to 2.0

[rdonnay]

I had been struggling with a problem with an Xbase++ app that uses a FOXCDX driver.
It would work properly under 1.9 but not 2.0.

I finally discovered that I needed to rebuild my CDX indexes.
Now it works fine in both 1.9 and 2.0.

Prior to doing this, a skip would fail on some indexes.

[bobvolz]

Roger ;
I can attest to the need to reindex. I was told in Arizona that I could run parallel 1.9 and 2.0 versions working on the same database.
Actually, I could do this until I moved to your release 263- My guess is that 263 is created with a newer version of xbase 2.0 than 261 was.
I downloaded all the new Alaska releases and am currently on 644 runtime dlls.

When I first compiled the system in express 263 it compiled fine. When I went to run it could not perform a seek on my security file and thus errored out because some variables were not established from the seek. Just for giggles I copied your 261 DLLs back to the working directory and all of a sudden it worked fine. Finally I surmised that I really needed to reindex everything under 263 which I assume uses the latest Alaska versions 644.

It all appears to work now that I have recreated every index. This makes it a little harder to deploy since I was expecting not to have to delete all the indexes for all my installations.

Any thoughts on this.

Bob Volz

[rdonnay]

Bob -

This doesn't make sense to me.
eXpress++ doesn't do any indexing.
It's done by the Xbase++ runtime.

Roger

[bobvolz]

It didn't make any sense to me either- but I'm not making it up. It happened to me on all 3 of my computers.

I was running duel systems for a month or so at Meadowland using the same database and indexes. AutoMan on 1.9 and AutoMan on 2.0
After a complete recompile with express 263 My 2.0 version of AutoMan could not find a seeked record that it needed to establish some other vars and static functions. The next functions after the seek crashed as a result. I was figuring the new version of 2.0 ver 664 was the problem but if I just copied the old version 261 dlls back to the runtime directory without even recompiling I didn't get the errors.
Bobby D thinks I have an environment problem but I think reindexing is the only solution.

I'm going to fool around with it again today.
Thanks

Bob Volz

[Wolfgang Ciriack]

I had the same problem when changing from express version 261 to 263. My app freezes ("this program does not work anymore" from windows).
After a rebuild of all index files it was ok again.

[bobvolz]

I knew I wasn't crazy!.

At least not this time.

Bob Volz

[Victorio]

Hi,

I found this thread now, please have you some new about this problem ?
I have similar problem, but with VFP 9 indexes CDX. Xbase read it, but have problem with seeking, listing in browser, when set order to any character field.
After reindex works fine, but I cannot reindex database VFP (because on VFP run paralell other aplications, and I must read this database with CDX only in read only mode)
I have Alaska Xbase 2.0 build 554 and Express 2.0 build 260

[rdonnay]

I now understand that I am probably the person who created this problem in eXpress++ build 264.

If you use any function that will cause DCLIP1.DLL to load, then it will also call an INIT function that loads a bunch of DBEs.

I made a change to the FOXCDX driver when it loads.

Code: Select all

 
  DbeSetDefault('FOXCDX')
  DbeInfo( COMPONENT_DATA, FOXDBE_CREATE_2X, .T. )
  DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE , FOXDBE_LOCKMODE_2X )
  DbeInfo( COMPONENT_ORDER, CDXDBE_MODE , CDXDBE_FOXPRO2X )

I inadvertently left this code in _DCINIT.PRG when I was testing some things for a customer.

In build 265 it will be set back to its orignal state:

Code: Select all

  DbeSetDefault('FOXCDX')
  DbeInfo( COMPONENT_DATA, FOXDBE_CREATE_2X, .F. )
  DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE , FOXDFBE_LOCKMODE_VISUAL )

You can easily override this in your application by putting the above code in your MAIN procedure because it will load after all INIT procs.

[bobvolz]

Hi Roger;

I had this problem with the first release of 264 disguised as 263 . The new release of 264 did not have this issue. That's why I finally converted to Alaska 2.0 because I could share cdx indexes with Alaska 1.9. I have completely switched from 1.9 to 2.0 and did not reindex anything although it's still probably good practice to do so.

Bob Volz

[omni]

Roger,


This is apparently related to the issue i had with all my users going to 2.63 with that library and loading the dbesys with those exact fox...commands. They had all sorts of index problems. Their programs would run but random files with indexes would just lock up with no option but to totally replace the file with a fresh file that is reindexed and append the data.
That is on a current question/request where you said you would need to see it...but its hard to do that when its arbitrary. I could not repeat it here because apparently all my files were re-indexed at some time.

Do i just need to delete that one line and retry it? I am not using that library right now and also not using dbesys. This is all non-ads.

Here is what we were given to use when their were initial problems. Still had problems after adding this also, just not as many.

DbeSetDefault('FOXCDX')

DbeInfo( COMPONENT_DATA, FOXDBE_CREATE_2X, .T. )
DbeInfo( COMPONENT_DATA, FOXDBE_LOCKMODE , FOXDBE_LOCKMODE_2X )
DbeInfo( COMPONENT_ORDER, CDXDBE_MODE , CDXDBE_FOXPRO2X )



Fred
Omni