Update Performance Using Different DBESYS

[bobvolz]

I converted my app to FOXCDX from DBFNTX a year or so ago.

When doing the conversion I only converted the DBF files that had DBTS. Basically I created a program that copied the structure of theses files and created a new file via FOXCDX. I left the rest of the files as is and just created cdx indexes.

I noticed a slowdown in the daily batch update from that point forward. After a discussion with Roger I did some analysis with dc_dbesys() and it seems that 3 of the 5 files involved are still type 3 (Clipper compatible) while 2 are type 48 (True Visual Fox Pro)

I intend to get these all to the same DBE in the near future. I was just wondering if any of you had any similar experiences and do you think having a consistent DBE will speed up the update.

Bob Volz

[Cliff Wiernik]

I have only used the adsdbe with cdx files since about 1995 so I don't have a reference point with the dbf/ntx file format. Sorry to not have any additional information for you.

[messaoudlazhar]

hi,

When converting my dbase since NTX to CDX, I created a procedure that converts DBT base toward FPT

Procedure ConverT_NTXCDX
Local FileDbf,kn,ixi,fichdbf
If ! DbeSetDefault() $ "FOXDBE*FOXCDX"
RETURN
Endif
FileDbf:=Directory("*.DBT")
If len(FileDbf)>0
kn=len(FileDbf)
For ixi=1 to kn
BEGIN SEQUENCE
if file(FileDbf[ixi,1])
fichdbf:=StrTran(FileDbf[ixi,1],".DBT","")
use (fichdbf) VIA "DBFNTX"
**- Temporally file
Copy to temp
use temp
**- then initial file
Copy to (fichdbf)
use
**-- Erase DBT File
fichdbf:=FileDbf[ixi,1]
erase (fichdbf)
**-- Erase CDX File if found
fichdbf:=StrTran(FileDbf[ixi,1],".DBF",".CDX")
if file(fichdbf)
erase (fichdbf)
Endif
**-- Erase NTX File if found
fichdbf:=StrTran(FileDbf[ixi,1],".CDX",".NTX")
if file(fichdbf)
erase (fichdbf)
Endif
Endif
END SEQUENCE
Next
Endif
RETURN

Best regards

[bobvolz]

Hi Messoaudlazhar

Thanks for the info. I also wrote a program that converted DBFNTX files that had memos (dbts) to FOXCDX

I did not however convert ALL my files to FOXCDX (I left all non memo files alone) What I am finding today is that when
I analyse my files with Rogers dc_dbetype() function I see that some of my files (the ones I converted) are file type 48 Visual Fox Pro while the ones I left alone are type 3 Clipper/DbaseIII.

My question to the community was does having an update that involves files that are of different dbetypes slow it down?
My daily update uses several files. At least 1 of them is Visual Fox Pro while the other 4 are Clipper/Dbase.

Thanks for reading my Post

[Tom]

There are three major differences between "classic" DBFs and those for/with FOXCDX:

1. The compound indexes (if wanted)
2. FTP instead of DBT, so binary data can be stored, optimized storage use
3. Clipper-DBF is ALWAYS in OEM charset, no matter what switch is used inside the software. So, if the software is in ANSI and uses ANSI, the data from/to those tables is converted (even when accessing the index files) from and to OEM. FOX can be in OEM or ANSI, depending on the settings when the table was created

[bobvolz]

Hi Tom;

Thanks for the info. I am getting ready to convert to ADS in the near future so that is why I wanted to get 'consistency' with my databases.

If I convert ALL of my files to FOXCDX format (that would be Visual Fox Pro Format) would that pose any problems or considerations when I convert
to ADS. Bobby Drakos thought that ADS with Visual Fox Pro file formats might be problematic.

Currently, if I create a new file from an xBase++ program it creates a Visual Fox Pro file. Roger's xDot creates Visual Fox Pro as well.

I believe there is a parameter to create Fox 2.x files but I was obviously unaware of this at the time I did the original conversion from DBFNTX to FOXCDX.

You have recommended in other threads that the FOXCDX driver be used with ADS- but which one do you use- Visual Fox Pro or Fox2.x ? .
I just don't want to go down the wrong road here.
Currently I have about 30 files that contain FPT's that are all in Visual Fox Pro Format. type 48 if you use dc_dbetype()
The other 100 or so that did not have memos are in Clipper/DbaseIII format. type 3 if you use dc_dbetype()
I know you are well versed in this subject so I would greatly appreciate any advice.

Thanks again
Bob Volz

[Dian]

We have been using Fox 2.6 files with ADS for many years and have never had any problems. Memo fields cause no problems. Prior to switching to ADS use used the FOXCDX DBE with the following settings so that we could access the tables with our FoxPro application as well as our Xbase application.

QDEFAULT_DBE:='FOXCDX'

DbeInfo(COMPONENT_DATA, FOXDBE_LOCKMODE, FOXDBE_LOCKMODE_VISUAL) //NEEDED TO PERFORM RECORD LOCKING WITH FP26
DbeInfo(COMPONENT_DATA, FOXDBE_CREATE_2X,.T.) // CREATES FILES COMPATIBLE WITH FP26
DbeInfo(COMPONENT_ORDER,FOXDBE_LOCKRETRY,1000000)// to increase index unlocking retry
DbeInfo(COMPONENT_ORDER,FOXDBE_LOCKDELAY,10) // to increase index unlocking retry

[bobvolz]

Hi Dian;

Thanks for the info. I guess I missed that part of the training to set the dbeinfo to create FoxPro 2.x files. The default behavior of xbase is to create Visual Fox Pro files. That is also the default in xDot. When I converted from dbfntx to Foxcdx I did not set that parameter.

I believe it will all work OK with Visual Fox Pro files based on what I am hearing from others. I just don't want this to blow up in my face when I convert to ADS.

Bob Volz