RE: dbimport feature/bug on 9.40HC3

Well, it helps sometimes to be obstinate, pig headed, passionate, and persistent. I think we can all see from the subsequent posts on this subject that IBM have acknowledged they got it wrong. They have put it right (thye think) in future releases by adjusting the calculation. However the calculation will always be wrong if they persist in adding the full length of VARCHAR when calculating row size. That is what causes the problem with even the smallest databaes (e.g. my speciality - the stores database). People have commented on this effect being different for different tables - and that is down to the VARCHAR effect. IF anybody from IBM is listening a better procedure would be to assume empty varchars when calculating row size. OK this will not keep the whole table in one extent after loading but will be more correct. OR how about factoring in the size of the unload file when VARCHARs or BLOBs are involved. Regards Malcolm -----Original Message----- From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org] On Behalf Of Christopher Sent: 28 April 2005 18:56 To: informix-list@iiug.org Subject: Re: dbimport feature/bug on 9.40HC3 I shared this problem with Informix Tech Support and could not get them to acknowledge the bug, so you've gotten farther than I. What I did was create the stores7 database (dbaccessdemo) in IDS 7.31, then exported it without the -ss, then imported into IDS 9.40.xC3. I used Solaris, AIX, and Windows. Oddly, Solaris took the most space. However, the database took about four times the space. The sysprocedures table took eight times the space, alone. Next, I tried creating the database in IDS 9.4 with the dbaccessdemo7 program. It took more space than on IDS 7, but not nearly as much as the dbimport. Tech Support told me this was expected behaviour. No, I do not believe that, and, no, I could not get past this response. As Neil has noted, the space wastage comes from widely mis-calculating extent sizes. This might be acceptable if I am importing a production database that is going to grow, anyway, but a lot of the imports, especially those without the dbexport -ss, are for test databases that are never going to grow. Now, some people have recommended estimating the extent size and putting those in the file. One suggestion was to estimate based on row size from the SQL file.What we discovered was that this number was consistently lower, by an appreciable margin. There always seems to be more overhead than we calculated. Part of the problem is the indexes, especially those for constraints not built upon named indexes. Sincerely, Christopher Coleman Database Analyst Medication Management Mediware Information Systems, Inc. sending to informix-list

And I suppose IBM could argue a better procedure could be to dbexport with the -ss option

"scottishpoet" <dryburghj@yahoo.com> wrote in message news:1114765779.819666.37350@o13g2000cwo.googlegroups.com... > And I suppose IBM could argue a better procedure could be to dbexport > with the -ss option It would be quite a poor argument though, wouldn't it? It would make a big, and often incorrect, assumption that the target dbspace will be the same as the source for example.