Beth,

There're two string literal delimiters: single and double quotes. The single quote is the one I would recomend to use. You've to double single quotes in the string literal if there's one. For example

WHERE name = 'O''Neil'

The double quote can also be used but it's an ANSI standard for identifier delimiters and it's interpretation by SQL server is controled by SET QUOTED_IDENTIFIER setting at parse time. See BOL for details.

You can also consider using textmerge to build SPT statements. It makes code more readable and easier to maintain.

TEXT TO lcSql TEXTMERGE NOSHOW PRETEXT 7
Insert into <<paKeys(2)>>  values ( <<CHRTRAN(pcInsertStr, ['], ['']>>) 
ENDTEXT

>Morning all,
> I am working in both vfp6 & 8 and SQL Server 7(2000)? - I think that is the name of it, well, the newest one out, not as a Bata.
>
> I need to pass a string that is composed of text and numeric data separated by commas as the values to be put into a table. The string is setup so that the data corresponds to the columns of the table. I tried just putting the data string into the insert statement as follows:
>

lcSqlStr = "Insert into " + paKeys(2) + " values (" + pcInsertStr + ")"

>
>but the ODBC error I get says that the first item in the pcInsertStr is a column name and not allowed. So I put single quotes around the whole string :
>

lcSqlStr = "Insert into " + paKeys(2) + " values (‘" + pcInsertStr + "’)"

>
>But on certain data strings this does not work, such as a text string containing a ‘ for such as O’Brian. And I can not get rid of the quote, because the clients scream that they are needed.
>
>I tried putting the data into another string with the insert set command:
>

  lcUpdateStr = lcUpdateStr + 'set ' + paFields[lnloop, 1] + ' = "' ;
>          + ALLTRIM(laFld[lnloop]) + '", '

>But get the ODBC error of incorrect syntax near set.
>
>Does anyone know of a better way to do this?
>
>I am looking at parsing the string on vfp side into an array, then either putting the data into a vfp or sql temp table and import into correct table from there. But that sounds like a lot of work and slow. I am hoping someone else can come up with a better suggestion.
>