Thanks for the tip about using VFP variables as parameters with stored procedures. I think that is the way I will go. I have done a little testing with this, and it appears as though the variables must be PRIVATE, rather than LOCAL. Is this what you have found?

>>My questions are:
>>
>>1. Should I be using a Text fiel in SQL Server? I upsized from a VFP database, and the source field was a memo field.
>
>You could use VARCHAR(8000), but I've used TEXT myself without any problems and I prefer using TEXT for that case.
>
>>2. Is using a stored procedure the best way to handle inserting and updating records, or shoudl I just issue the INSERT from VFP?
>
>Using stored procedures allows you to have better control over security. I think it's the right choice.
>
>>3. When I am building my SQL string in VFP, what do I do if one of the parameters to the sproc contains a '?
>
>Double it, like this:
>
>[EXEC spCompanyInsert @CompanyID = 1, @PrincipalBusinessDescription = 'Lot''s of things!']
>
>SQLServer will not put 2 quotes there; it will understand what you want. If you are doing something like this to create your SQLExec() command:
>
>cSQLString = [EXEC spSomething @var1='] + m.MyVar + [']
>
>you can use the STRTRAN function:
>
>cSQLString = [EXEC spSomething @var1='] + STRTRAN(m.MyVar, ['], ['']) + [']
>
>Finally, if you are using a variable that will be in scope when SQLExec() is called, or using a field name, you can use the question mark:
>
>SQLEXEC(nConn, [EXEC spSomething @var1=?m.MyVar])
>
>Note that there are no quotes around the var name, and you don't need to double the single quotes in the m.MyVar variable. VFP will send the string correctly to SQL Server.
>
>Hope this helps!