Converting VO memo field data to a SQL Db

[Chris]

Hi Nick,

Unfortunately I am not very familiar with the implementation of the memo part of the RDDs, I will have a look into it and will get back to you, but maybe Robert has a faster and better suggestion on that matter?

About the _SET_MEMOBLOCKSIZE (and other) defines, you can add a reference to the SDK_DEFINES.dll file in the XSharpVOXPorter folder and it will be visible. Or you can add a #include "VOSystemLibrary.vh" in your prg file.

Chris

[NickFriend]

Hi Chris,

I've been testing this thoroughly this morning. Results are that basically having a non-standard memoblock size screws things up.

If I first convert the DBF (in VO) to use memoblock size 32, then I can use BlobExport or your code together with File.WriteAllBytes, and both create a file on disk with the correctly formatted data from the memofield. In other words I can use XSharp + Vulcan runtime to extract the data in the correct format which means I can then easily write it to the new SQL database.

But as soon as I revert to the original file and try to use Memoblock size 31, then everything goes haywire. I think that RDDINFO(_SET_MEMOBLOCKSIZE,31) only affects creation of new files, so presumably the Vulcan RDD has a problem reading non-standard memoblock sizes.

I'm going to do some more tests to see if I can use the Vulcan runtime to copy the offending (31) file to a new file with standard memoblock size and then read that (I could then use that as a quick and dirty solution to import the required data into our Net app), but I suspect the Vulcan RDD is going to muck that up.

Nick

[NickFriend]

As expected, CopDB doesn't copy the contents of the memo field. So it seems the Vulcan RDD chokes on a non-standard memoblock size.

Nick

[NickFriend]

Just in case anyone is interested, the only solution I've found has been the following.

I've created a VO COM component that copies the offending (31 byte memoblock size) DBF files to standard 32. The XSharp component calls the COM component to make temporary copies before proceeding... it can then use the Vulcan RDD to access the memo fields in the modified files and extract the data in the correct format using Chris's code. Then the temporary files can be removed leaving the system as before.

Very ugly but it works, until we get proper XSharp RDDs and runtime.

Nick

[Chris]

Hi Nick,

Thanks for the update. I also could not think of a more elegant solution, looks that indeed something is wrong in the vulan RDD with non standard memo block size. Yeah, that will be done properly in the X# RDDs.

Chris