home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cs.utexas.edu!sun-barr!news2me.ebay.sun.com!exodus.Eng.Sun.COM!sun!amdcad!weitek!pyramid!infmx!news
- From: cortesi@informix.com (David Cortesi)
- Newsgroups: comp.databases.informix
- Subject: Re: question on load vs. count(*) counts
- Message-ID: <1992Sep1.165712.21321@informix.com>
- Date: 1 Sep 92 16:57:12 GMT
- References: <9427@emory.mathcs.emory.edu>
- Sender: news@informix.com (Usenet News)
- Reply-To: cortesi@informix.com
- Organization: Informix Software, Inc.
- Lines: 27
-
- In article <9427@emory.mathcs.emory.edu> Root@letterkenn-emh1.army.mil writes:
- > If the error is 846 Number of values in load file not equal to # columns, the
- > count displayed is 42, and "select count(*) from table" also yields 42.
- >
- > But, when the errors was either 391 cannot insert a null into column, or
- > 239 could not iinsert new row - duplicate value in unique index column
- > the count displayed is usually 48 (always a multiple of 16). The error
- > occurs within 16 rows before the displayed count. "select count(*) from
- > table" displays a count of existing rows which is always less than the
- > loader said, but not more than 16 less.
-
- Pretty clearly, LOAD is counting input rows but using an insert cursor
- and PUT to do the inserts. PUT blocks rows (probably blocks of 16 in
- your case!) before sending them to the engine where an error such as
- -391 would be detected. The count of rows could be adjusted based on
- the value PUT would return in the SQL Communications area, but it
- would appear this isn't being done. That would be my guess as an amateur
- esql/c programmer, anyway... This might be the same as bug #4465:
-
- Bug Number [ 4465]... Scheduled Fix Ver [ ][4.00.UC1A3]
- .. Closed [10/12/89]...
- Short Desc [LOAD DOES NOT SET THE SQLERRD[2] SET TO # OF ROWS PROCESSED ]
- Long Bug Description
- [Because of the fact that sqlload was not setting the sqlerrd[2] ]
- [flag that indicates the number of rows that were inserted, 4gl ]
- [programs has no way of finding out if the rows were processed ]
- [correctly. ]
-