Jump to content

Rob Donovan

Member Since 31 Jan 2000
Offline Last Active Jun 19 2018 10:49 AM

Posts I've Made

In Topic: cisam FILEDEF change questions

16 May 2018 - 06:58 AM

Yep, that is correct.


You will need to write a Lookup / Add Update to convert each file if you change lengths, types or order of any fields.

In Topic: c-isam bcheck -s

16 April 2018 - 09:19 PM

Great! :)


I would use compress on indexes, yes.


If any external system is also referencing the compressed files, then they should be using the standard C-ISAM routines, which will allow them to access them fine with the COMPRESS flags set.

In Topic: c-isam bcheck -s

16 April 2018 - 12:29 PM

Richard got most of it... :)


As for my defrag, this is what it does:


Reads the file in key order, and then writes out a new file in that order.


What this does is remove any 'deleted' records that haven't been overwritten yet, puts the .dat file in key order so makes accessing seq records quicker (and possibly in the same block read), and reduce the size of the .idx file as it is packed better if its in order and reduces BTREE levels, which makes indexing faster.


All of this helps performance and also reduce the size of the files.


As far as I am aware, there is no other util that does this, and I would strongly recommend that this is done on the whole system every 6 months or so. (Note: System must be 'offline' to do this)


The bcheck -s thing resizes the index node. I looked into this some years ago, and could not find any particular increase in performance changing this. The biggest saving is defragging. 

In Topic: pro-isam versus c-isam

25 March 2018 - 02:58 PM

I would think they are all fairly similar for 'stability' TBH.


We used COMP3 from the start (starting back in 1994) probably for size, since the only reason we went to CISAM then was the size limitations on ProISAM back then.


We had external C++ code that read our C-ISAM files after a while, so we just got them to decode the COMP3s.

In Topic: pro-isam versus c-isam

25 March 2018 - 02:08 PM

Obviously, ALPHA for strings.


As for numerics, I've used a mixture, can't quite remember why TBH, sorry... I think it could have been in the past there was some bugs with them.


Think small numerics under 4.0 we used 'ZONED' which saves them as strings, and then COMP3 for anything else, because COMP3 had a problem with smaller numbers if I recall correctly.