>Hiya Todd ----

> Hope I can help with a few of these issues 'cause, boy, do they sound familiar :-)

Yeah! I feel better just knowing that I am not alone! :-)

>
>>Ok... Problems with this methodology: 1. Unless all the character fields are changed into type MEMO they are inserted into the second
database with trailing spaces. Not horrible, except the commerical package was
> Try changing the views data type to Character(Binary)...or, maybe, PADR() the ALLTRIMmed value with CHR(0). Or, import *all*
character fields from the commerical program and save them back as padded with blanks for consistancy.

Padding with chr(0) didn't seem to help... but I'll give the binary field type a try... MEMO fields also solved the problem, so this one isn't a show stopper, just a pain in the neck!

>>2. Date fields are giving me serious fits. About half the time, it tells me that it can't convert date/time values (ODBC error) and the other

> Yup. ODBC (I think) cannot handle blank dates well and you're at the mercy of the database engine and/or VFP as to how they are
defined. Try converting the views date fields to DateTime and set them to allow nulls. When saving a record with a blank date (which Fox
allows), save a .NULL. instead.

Using datetime fields is worth a shot. I was thinking about trying to convert them all to character fields, and see if my insert command would translate the field type on update. (ie, I would DBSETPROP on my local view to change datatype = C(10) and then stuff a DTOC() value into the field.

Any thoughts on using INSERT instead of some fancy SQLEXEC() command?

Thanks for the reply man! I've been really down about this today.

Todd

ps, great tag line!