Data Read Error (OpenInsight 32-Bit)
At 01 MAY 2008 11:06:34AM Richard Richter wrote:
I am using OI 8.0 on Windows XP, 2000, 2003 Server. I'm having the same problem on all operating systems.
I have a form that writes a file containing 9 fields. Within each field there can be as many values as needed and each value will contain 41 subvalues. When the data file is created, there is no problem. The data writes to the table perfectly.
When the file is read back into the form, the number of subvalues is cut off at between 10 and 11 subvalues. I have tried a READ send-event to set the data directly into the db table and i have programatically read the file and got the foreshortened data.
Does anyone have any ideas how I can retrieve all the data?
Thanks,
Richard Richter
At 01 MAY 2008 11:18AM Clay wrote:
When you edit the record directly. Does it contain the correct data?
At 01 MAY 2008 11:19AM Mike Ruane wrote:
Richard-
If you're reading into a form, specifically an EditTable control, what is it set to for data length?
Mike
At 01 MAY 2008 11:51AM Richard Richter wrote:
It is cutting off whether I read it directly into the edit table or or in an event, open the table and read in the file to a variable.
At 01 MAY 2008 11:52AM Richard Richter wrote:
No. It is cutting the data short whether I read the data directly into an edit table or use an event and open the table and read in the file to a variable.
At 01 MAY 2008 11:57AM Clay Borne wrote:
Are you sure that the data is getting initially written to the table properly? You should debug the process that writes to the table and verify that the problem is not something else.
At 01 MAY 2008 01:04PM Richard Richter wrote:
You are absolutely right. The data is being cut off when it is being retrieved from the db edit table from the event handlerrior to saving the record. What is going on? all the data shows in the data table. Help.
Richard Richter
At 01 MAY 2008 01:42PM Mike Ruane wrote:
EditTable columns (in their properties) have a display width and a data length- both default to 80. The data length specifies how many characters from the column in question will be saved.
Change the data length to some large number - 999 or 9999 - and try from there.
Hope it helps-
Mike
At 01 MAY 2008 01:50PM Bruce Cameron wrote:
Richard,
Try creating a new form bound to your table.
Add the item id field(s).
Add an EditBox control
Bind it to your attribute/field in question.
Run the form, enter an id and look at the data in the edit box.
Are all the @VM's and @SVM's there?
Are there any @RM or @FM's or other?
If it looks good then it sounds like it is what Mike is referring to.
HTH
At 03 JUN 2008 11:45AM Karen Oland wrote:
Mike,
His problem is no doubt that he is using subvalues (not data length - I ignore this value and have tables with hundreds of items that retrieve with on issue).
Edittables despise subvalues, as implemented. To make it work, you must change the subvalue marks to something else during the read event, then change them again prior to the write (they will read and write ok, but you can't use them the rest of the time or the edittable control removes data). Since I use SRP's OLE edit table control, I simply added the required code as a promoted event (to read and write), then stuff the info into the SRP control, where I can deal with the subvalues (and you still need custom code to handle them).
Running reports is another problem (and always has been). Subvalues simply don't get parsed out correctly (at least thru 7.x) in the default report processor or in S/List (despite their many attempts to get it working). I have one report that is on a table that uses subvalues - it looks "better" than in some iterations, but has never looked "correct", in that it never parses correctly as it does in AREV. I haven't tried this in 8.x yet (and may not, as losing S/List's other capabilities would probably not be worth the hassle).
If you use subvalues in OI, you are in for a lot more coding - both for windows and for reports. It simply doesn't work as easily as in AREV (and the same is true for sub-text marks, to some extent).
At 03 JUN 2008 12:26PM dbakke@srpcs.com's Don Bakke wrote:
FWIW,
One way of avoiding the whole delimiter swap requirement is to use hidden editlines (or editboxes) rather than hidden edittables. There is a loss of convenience of simply being able to swap arrays from the OI edittable to the OLE EditTable, but it affords other advantages. Plus, once you do this enough times you tend to write generic code to handle the data transfer for you and thus it no longer matters to whether the hidden control(s) are edittables or other edit controls.
dbakke@srpcs.com
