Teddy Jensen (02/26/2010)
Edhy - You are normally very fast in posting your results, so I would like to know if You got it working ?
Hmmmm, that must be a bad habit
just kidding
Seriously, I am still working on this but I went a different approach based on the application requirements which are as follows:
1.- The CSV data saved in the varbinary field is used once or twice. The data is imported into a table and once the records are imported this CSV data is not used anymore unless there is a problem with the imported records and the CSV needs to be imported again.
2.- Based on number 1, I don't need this big field value being loaded in any way during normal operations unless I need to read the CSV again to re-import the records.
So this is what I did:
1.- Create a new table related to the main table. This new table will have the varbinary field.
2.- In the main table BO, create a new property to read the varbinary field from the related table. This will free the main table from this field and speed up the loading process of forms using the main table.
3.- I added a new child form dialog to manage the request for getting the varbinary field via the BO property.
During this process, I am also playing with compressing the CSV data once it is converted to a byte array using System.Text.Encoding.UTF8.GetBytes(value), the compression looks pretty good since one of the CSV file has 9.3 million bytes and when compressed will have 2.6 million bytes. I am not using the .Net compression classes since I have a 3rd party library to handle many things, but I am sure the plain .Net class could do the same.
I am still in the process of refining the custom field property to properly handle getting the varbinary field, decompress it and convert it back to text to be shown in the child form dialog so when I am done I could post some code.
Trent's suggestion here is pretty good and would work for me if I would have to show the CSV data all the time when opening the form, but that is not my case for now
Edhy Rijo