0005449: JvCsvDataSet has difficulty setting field sizes to something longer than 80 characters for strings - JEDI Issue Tracker

ID	Project	Category	View Status	Date Submitted	Last Update

0005449	JEDI VCL	00 JVCL Components	public	2010-12-27 16:54	2011-06-07 17:34

Reporter	Gary_M_Mugford	Assigned To	obones
Priority	normal	Severity	minor	Reproducibility	always
Status	resolved	Resolution	fixed
Product Version	3.40
Target Version		Fixed in Version

Summary	0005449: JvCsvDataSet has difficulty setting field sizes to something longer than 80 characters for strings
Description	JvCsvDataSet was used to set up a link to a file where there were five string fields in a comma-delimited record, each record separated with crLF's. The desired length of each field in order was 30,3,253,253,3. The fields came up as 80 characters wide and no amount of fiddling on my part would change that. I tried changing the field width at run-time. I deleted and recreated the component a number of times. In each case, the assignation of the width of the field data-wise was 80. I have no idea where that number came from. The issue seemed harmless enough until I ran it against one file that did, in fact, have more than 80 characters in the third and/or fourth fields in some records.
Additional Information	I loaded the file, using a TJvFilenameEdit into a memo, where I deleted the first empty line and then replaced the second line with Fld1, Fld2, Fld3, Fld4, Fld5. (During experimentation, I also used "Fld1" type naming conventions. No difference. I then exported out to a copy of the original file with the CSV extension so that I would not be affecting the original. THEN I activated the CSVdataset, which loadeed the file. This all took seconds at the most. There was only about 90K records. I then displayed the whole thing in a grid right from the standard delphi Data Access tab. At the same time, I coped the structure of the CSVdataset to a KBMmemtable (a commercial in-memory table). I then looped through the CSVdataset and checked for two conditions, either of which would result in the copying of that record to the KBMmemtable. At the conclusion of the loop, I then printed a report through ReportBuilder. Initially, I saw no problem. Then, when I noticed the truncated data in a second test, I started checking and found CSVdataset's dogged determination to default the string fields to a length of 80 and stick with it. I WAS able to produce smaller numbers than 80 in terms of display in the grid for the smaller fields. Trying to increase the space and allow for the importation of wider data in Fld's 3 and 4 failed continually. I changed the ReportBuilder report to use a memo for the contents of thos two fields and it showed no more than 80 characters in each of the problem fields. I put in a variable on length of the contents, looking for a maximum, during the looping and found the maximum in the CSVdataset for each of the two fields was 80 characters. The truncation was occuring there. Eventually, not finding a solution to the CSVdataset truncation issue, I opted to use a second KBMmemtable as its replacement and now have a functional application. As such, I am entering this into the Tracker as an academic exercise. But am curious as to whether it's something strictly in my setup or is actually a bug. My setup is, in fact, somewhat unstable. SETUP: Delphi 7 running on WinXPSP3, 4G of ram, Many, many components, too numerous to list. The application included the two previously mentioned Jedi components, a Jvcl Datasource, some basic Delphi buttons, and the aforementioned commercial libraries, KBMmemtable v5 and ReportBuilder v7.
Tags	No tags attached.

Date Modified	Username	Field	Change
2010-12-27 16:54	Gary_M_Mugford	New Issue
2010-12-29 22:55	jfudickar	Note Added: 0018263
2010-12-29 22:56	jfudickar	Status	new => feedback
2011-06-07 17:34	obones	Note Added: 0018583
2011-06-07 17:34	obones	Status	feedback => resolved
2011-06-07 17:34	obones	Resolution	open => fixed
2011-06-07 17:34	obones	Assigned To	=> obones