My supervisor uses Paradox 10 for all his reporting for well over a decade.
Just recently, he has encountered a "table full" error. He is working with
a very large set of data; over 416,000 records with 300 columns per record.
His systems is running XP Professional with a P4 running at 3 GHZ with 2
Gigs of memory. While searching the web I found a reference to a fix that
involving changing the block size.

Can anyone suggest a fix or point me in the right direction t fix his
problem.

David Macias
Research Technician
CSUDH
Institutional Research
dmacias (AT) csudh (DOT) edu

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

He isn't using paradox if he has 300 columns in a table. Pdox doesn't support
that many. And anything even remotely approaching the max (255 or 256 IIRC)
seriously needs normalization. You may want to look at my paper on
Normalization at our paradox resources page ( link in my signature).

If you really ARE using pdox tables you can increase the table capacity by
creating a NEW table with the new block size and then moving the old data to it
but you can't change the block size of an existing table. But seriously,
416,000 records isn't all that much. The problem is that you need to properly
normalize the data.

Denn Santoro
President
Resource Development Associates
http://www.RDAWorldWide.Com
Offices in the United States and Germany
Providing solutions to health care, business, governments and non-profits since
1982

dmacias666 wrote:

300 columns per record I assume to mean, 300 bytes per record, which at
~416000 records, nears the table limit for a table with 2k blocks.

Changing the blocksize should work. You have to change that setting in the
BDE Admin, and you also have to recreate the table, then add the existing
data back in to get a table with the desired blocksize. Just changing the
setting won't affect existing tables.

--
Larry DiGiovanni
Digico, Inc.
IT Consulting and Staffing Solutions
www.digicoinc.com
Check out www.thedbcommunity.com for Paradox resources.

dmacias666 (AT) LABridge (DOT) com wrote:

Here's the basics...

A Paradox table consists of up to 65,535 "blocks" of information, each
containing an integral number of records. (There are 6 bytes overhead per
block. Records do not wrap-around.)

From this, knowing the block-size, you can calculate the maximum theoretical
capacity of an _unkeyed_ table. But here's a catch: the index files have
the same architecture, and they contain not only abbreviated records ("just
the keys, ma'am...") but also a B-tree index structure. When any index is
full, so is the table.

If you have a very, very large amount of data and are starting to run into
table-capacity issues, you should look carefully at the overall strategy of
the application: can the information be subdivided into smaller tables?

----
ChimneySweep(R): Fast(!) table repair at a click of the mouse!
http://www.sundialservices.com

Hi Larry,

Although creating a new table is the recomennded approach in upgrading a
block size, I sometimes use the table repair utility to change the block
size or even the table level. I always make a backup ofcourse and I alway
note the number of records in the original table before using the table
repair.

Gene


"Larry DiGiovanni" <nospam (AT) nospam (DOT) com> wrote

Gene De Guzman wrote:

I guess I have a stigma against using Table Repair on an otherwise perfectly
healthy table. :-)

--
Larry DiGiovanni
Digico, Inc.
IT Consulting and Staffing Solutions
www.digicoinc.com
Check out www.thedbcommunity.com for Paradox resources.

Gene,

It was my understanding that the Table Repair Utility's (Tutil32) Block Size
parameter was only to be used if the table header got corrupted (so it forgot
what the block size was), not to alter the table's block size. I've tried
this approach and always end up loosing lots of records.

There is a handy tool to change the block size - PXRest. I think I found
it on the Borland site (based on direction from this NG, of course). I've
used it lots of times without any issues.

Let me know if you can't find it.

Thanks,
Jim Moseley

Dear Jim,

I do experience data loss sometimes and what I do is empty the table and
append from backup after using table repair to increase the block size.

There is a utility I found in the DELPHI group for upgrading pdox tables,
changing blocksize, adding indices or passwords and many more and it never
loses records and it has a text-based scripting that allows you to run it
within padox and specify parameters. Here's the link:

http://www.rksolution.cz/Delphi/pxupgr.htm

These are some of its features:

Presented package gives the 32 bit Delphi programmers a tool for changing
Paradox database structure at run time. Instead of having to call different
routines for different types of structure changes, all supported restructure
actions can be achieved by invoking the single routine exported by the core
DLL. This routine accepts zero terminated string argument - PXUPGR command -
that is parsed internally by the core DLL. Thanks to this arrangement, the
description of all necessary structure changes can be stored outside the
main application in the form of script text files. This, in combination with
LOG files that store the results of database structure updates, makes the
maintenance of evolving database structure extremely easy.

The package also includes FREE script editor that simplifies PXUPGR script
creation. Editor main features are the ability to create scripts based on
the structure of selected database as well as differential scripts. When
creating differential script, you select "source" and "destination"
databases. Script editor then creates the sequence of PXUPGR commands that
convert structure of the "source" database to the updated (target) version.
You can also apply edited script to selected database.

The core DLL supports following restructure actions:
adding/dropping fields
changing field name/size/type
moving field to desired position
adding/dropping indexes
adding/dropping validity checks
adding/dropping referential integrity constraint
changing table level, block size, fill factor, strict ref.integrity,
name, language driver, master and auxiliary passwords
creating new table/dropping existing table
batchmoving data from one table to another
executing SQL action queries

The following lines show script sample that creates a table with structure
identical to that of table BIOLIFE from DBDEMOS database:
:================================================= =============================
: TABLE BIOLIFE
:_________________________________________________ _____________________________
: Fields: 8, Indexes: 1, Validity checks: 0, Referential integrity: 0
: Record size: Physical 179 b. Logical 163 b.
: Records per block: 11, Wasted space per block: 73 b. ( 3,56 %)
: Restructure version: 132
:================================================= =============================
:#1 Create table "BIOLIFE" with first field "Species No"
TBL_CREATE("BIOLIFE","ascii",4,"Species No",FLDFLOAT,FLDSTDEFAULT,1,0)
:#2 Adjust block size
TBL_SETATTR("BIOLIFE",BLOCK_SIZE,2048)
:#3 Adjust strict referential integrity
TBL_SETATTR("BIOLIFE",STRICT_REFINT,FALSE)
:#4 Add field "Category"
FLD_ADD("BIOLIFE","Category",FLDZSTRING,FLDSTDEFAU LT,15,0)
:#5 Add field "Common_Name"
FLD_ADD("BIOLIFE","Common_Name",FLDZSTRING,FLDSTDE FAULT,30,0)
:#6 Add field "Species Name"
FLD_ADD("BIOLIFE","Species Name",FLDZSTRING,FLDSTDEFAULT,40,0)
:#7 Add field "Length (cm)"
FLD_ADD("BIOLIFE","Length (cm)",FLDFLOAT,FLDSTDEFAULT,1,0)
:#8 Add field "Length_In"
FLD_ADD("BIOLIFE","Length_In",FLDFLOAT,FLDSTDEFAUL T,1,0)
:#9 Add field "Notes"
FLD_ADD("BIOLIFE","Notes",FLDBLOB,FLDSTMEMO,50,0)
:#10 Add field "Graphic"
FLD_ADD("BIOLIFE","Graphic",FLDBLOB,FLDSTGRAPHIC,0 ,0)
:#11 Add primary index
IX_ADD("BIOLIFE","","Species No","",PRI or UNQ)


Gene

"Jim Moseley" <jmose (AT) mapson (DOT) attglobal.net> wrote