Sqlprepare() vs Sqlexec()

[Hank]

Is there any advantage to using sqlprepare() and then running sqlexec
()? versus just running sqlexec()? And I seem to remember reading
that sqlexec has a limit of 255 characters is that correct? I've
searched the help file and can't locate where i read that.

[Hank]

Post by Hank
Is there any advantage to using sqlprepare() and then running sqlexec
()? versus just running sqlexec()?  And I seem to remember reading
that sqlexec has a limit of 255 characters is that correct?  I've
searched the help file and can't locate where i read that.

This is the code that is failing
nRetVal=SQLPREPARE(m.WorkingDatabase,'SELECT
userfname,userlname,ranchid FROM main_table.users; WHERE userid = ?
lcRanchUser AND password=?lcRanchPassWord', 'csrUsersOnServer')

nGoodCursor=SQLEXEC(nRetVal)

nRetVal returns 1
nGoodCursor returns -1
I've verified that the ?lcRanchUser and ?lcRanchPassword are in the
table. This is a MySql Database I'm working with using VFP 9.0

[Hank]

Post by Hank

Post by Hank
Is there any advantage to using sqlprepare() and then running sqlexec
()? versus just running sqlexec()?  And I seem to remember reading
that sqlexec has a limit of 255 characters is that correct?  I've
searched the help file and can't locate where i read that.

This is the code that is failing
nRetVal=SQLPREPARE(m.WorkingDatabase,'SELECT
userfname,userlname,ranchid FROM main_table.users; WHERE userid = ?
lcRanchUser AND password=?lcRanchPassWord', 'csrUsersOnServer')
nGoodCursor=SQLEXEC(nRetVal)
nRetVal returns 1
nGoodCursor returns -1
I've verified that the ?lcRanchUser and ?lcRanchPassword are in the
table.  This is a MySql Database I'm working with using VFP 9.0

Apparently you can't create a parametrized view using ODBC 5.1.4 (or
5) which is what I'm using, it's a MySql issue.

[Jack Jackson]

Post by Hank

Post by Hank

Post by Hank
Is there any advantage to using sqlprepare() and then running sqlexec
()? versus just running sqlexec()?  And I seem to remember reading
that sqlexec has a limit of 255 characters is that correct?  I've
searched the help file and can't locate where i read that.

This is the code that is failing
nRetVal=SQLPREPARE(m.WorkingDatabase,'SELECT
userfname,userlname,ranchid FROM main_table.users; WHERE userid = ?
lcRanchUser AND password=?lcRanchPassWord', 'csrUsersOnServer')
nGoodCursor=SQLEXEC(nRetVal)
nRetVal returns 1
nGoodCursor returns -1
I've verified that the ?lcRanchUser and ?lcRanchPassword are in the
table.  This is a MySql Database I'm working with using VFP 9.0

Apparently you can't create a parametrized view using ODBC 5.1.4 (or
5) which is what I'm using, it's a MySql issue.

Use AERROR after the call fails to see what error was passed back from
the ODBC driver.

Is there really a semi-colon after the FROM clause?

SQLExec does not have a 255 character limit. VFP has a 255 limit on a
single character constant. You can concatenate smaller strings
together or use TEXT / ENDTEXT.

[Juan Alonso]

Hank,

You can create any kind of parameterized view, especially using
SQL-PassThrough.

I use SQLEXEC() when I do mine and it works fine. I pass information to my
app for customer info, invoice data and inventory data without any problems.

I can tell you though that you have to use other SQL-PassThrough functions
that help to define the use of the fields from the table.

Let me see if I can get that code for you and post it here.

I was using it when I worked on a re-write instead of conversion, but they
went with conversion so I discarded it to my "use later" folder.

K will post when I get it.


Peace,

Juan

Post by Hank

Post by Hank
Is there any advantage to using sqlprepare() and then running sqlexec
()? versus just running sqlexec()? And I seem to remember reading
that sqlexec has a limit of 255 characters is that correct? I've
searched the help file and can't locate where i read that.

This is the code that is failing
nRetVal=SQLPREPARE(m.WorkingDatabase,'SELECT
userfname,userlname,ranchid FROM main_table.users; WHERE userid = ?
lcRanchUser AND password=?lcRanchPassWord', 'csrUsersOnServer')
nGoodCursor=SQLEXEC(nRetVal)
nRetVal returns 1
nGoodCursor returns -1
I've verified that the ?lcRanchUser and ?lcRanchPassword are in the
table. This is a MySql Database I'm working with using VFP 9.0

Apparently you can't create a parametrized view using ODBC 5.1.4 (or
5) which is what I'm using, it's a MySql issue.

[Bernhard Sander]

Hi Hank,

Post by Hank
This is the code that is failing
nRetVal=SQLPREPARE(m.WorkingDatabase,'SELECT
userfname,userlname,ranchid FROM main_table.users; WHERE userid = ?
lcRanchUser AND password=?lcRanchPassWord', 'csrUsersOnServer')
nGoodCursor=SQLEXEC(nRetVal)

SqlExec() requires as first parameter the statement handle that was returned by
SqlConnect, not the return value of SqlPrepare().

m.WorkingDatabase = SqlConnect(...)
nRetVal=SQLPREPARE(m.WorkingDatabase,'SELECT ... ')
nGoodCursor=SQLEXEC(m.WorkingDatabase)

Reread the examples of the help file at the respective topics

Regards
Bernhard Sander

[Pastorhank]

Post by Bernhard Sander
Hi Hank,

Post by Hank
This is the code that is failing
nRetVal=SQLPREPARE(m.WorkingDatabase,'SELECT
userfname,userlname,ranchid FROM main_table.users; WHERE userid = ?
lcRanchUser AND password=?lcRanchPassWord', 'csrUsersOnServer')
nGoodCursor=SQLEXEC(nRetVal)

SqlExec() requires as first parameter the statement handle that was returned by
SqlConnect, not the return value of SqlPrepare().
m.WorkingDatabase = SqlConnect(...)
nRetVal=SQLPREPARE(m.WorkingDatabase,'SELECT ... ')
nGoodCursor=SQLEXEC(m.WorkingDatabase)
Reread the examples of the help file at the respective topics
Regards
Bernhard Sander

Bernhard,

I did and I rewrote them to reflect what the docs say, and I can get
the statement to return a cursor as long as I don't have a 'WHERE'
clause in it. As soon as I put that in, it doesn't return a result
set, on the MySql forums it's listed as a known bug in MySql when
using ODBC 5.1 and VFP 9. My work around (luckily it's a small data
set) is to query the table bring down the two fields I need and then
run my comparison on them locally...

[Richard Stecenko]

How do you pass the value of the parameters to MySQL?

I've been doing this for the where clauses:

store "SELECT userfname,userlname,ranchid FROM main_table.users " +;
"WHERE userid like '" + alltrim(lcRanchUser) +"%' and ";
"password like '" +alltrim(lcRanchPassWord) +"%'" to dlcSqlExec

then either exec or prepare and execute.

For passwords and user names, I'd probably not use the % wild card,
but that's just an example.



Richard Stecenko
Interactive Computer Services Inc.
Winnipeg, Canada
204.453.2052

[JayB]

i think you are running into the 255 character limit of foxpro.
i always create my sql strings like this--
using your example :

text to lcsql noshow textmerge
SELECT userfname,userlname,ranchid FROM main_table.users
WHERE userid like <<alltrim(lcRanchUser)>>% and
password like <<alltrim(lcRanchPassWord)>> %
endtext
=sqlexec(xx, lcsql)

or

text to lcsql noshow textmerge
SELECT userfname,userlname,ranchid FROM main_table.users
WHERE userid = ?lcRanchUser and
password =?lcRanchPassWord
endtext
=sqlexec(xx, lcsql)

i dont think you need to trim anything or use the wildcard
there are many ways to do it.

also, i would think that mysql also will use standard sql parameters in
queries, although i cannot recall if i ever done so myself.

jay

Post by Richard Stecenko
How do you pass the value of the parameters to MySQL?
store "SELECT userfname,userlname,ranchid FROM main_table.users " +;
"WHERE userid like '" + alltrim(lcRanchUser) +"%' and ";
"password like '" +alltrim(lcRanchPassWord) +"%'" to dlcSqlExec
then either exec or prepare and execute.
For passwords and user names, I'd probably not use the % wild card,
but that's just an example.
Richard Stecenko
Interactive Computer Services Inc.
Winnipeg, Canada
204.453.2052

[Bernhard Sander]

Hi Jay,

Post by JayB
i think you are running into the 255 character limit of foxpro.

Hm, i think, the 255 character limit of foxpro has nothing to do with the
version of the MySql ODBC driver...

Regards
Bernhard Sander

[Roque Regalado]

You can work around the VFP 255 char limit easily by using a cursor with a memo field as a memory variable

Sample Syntax: use this only once at the beginning of your session and keep the cursor open during your session.

create cursor hlptxt (sql_str M)
select hlptxt
append blank
goto top
SCATTER MEMO MEMVAR

now you have a memory variable called "sql_str"
m.conn_handle = SqlConnectstring(.....)
m.sql_str = "Select ................... from etc etc etc ....." (this can be as long as you want)

Now you can use the m.sql_str in sqlexec
SqlExec( conn_handle, m.sql_str, 'cursorname' )

Post by Jack Jackson
Use AERROR after the call fails to see what error was passed back from
the ODBC driver.
Is there really a semi-colon after the FROM clause?
SQLExec does not have a 255 character limit. VFP has a 255 limit on a
single character constant. You can concatenate smaller strings
together or use TEXT / ENDTEXT.

Post by Bernhard Sander
Hi Hank,
SqlExec() requires as first parameter the statement handle that was returned by
SqlConnect, not the return value of SqlPrepare().
m.WorkingDatabase = SqlConnect(...)
nRetVal=SQLPREPARE(m.WorkingDatabase,'SELECT ... ')
nGoodCursor=SQLEXEC(m.WorkingDatabase)
Reread the examples of the help file at the respective topics
Regards
Bernhard Sander

Post by Richard Stecenko
How do you pass the value of the parameters to MySQL?
store "SELECT userfname,userlname,ranchid FROM main_table.users " +;
"WHERE userid like '" + alltrim(lcRanchUser) +"%' and ";
"password like '" +alltrim(lcRanchPassWord) +"%'" to dlcSqlExec
then either exec or prepare and execute.
For passwords and user names, I'd probably not use the % wild card,
but that is just an example.
Richard Stecenko
Interactive Computer Services Inc.
Winnipeg, Canada
204.453.2052

Post by Juan Alonso
Hank,
You can create any kind of parameterized view, especially using
SQL-PassThrough.
I use SQLEXEC() when I do mine and it works fine. I pass information to my
app for customer info, invoice data and inventory data without any problems.
I can tell you though that you have to use other SQL-PassThrough functions
that help to define the use of the fields from the table.
Let me see if I can get that code for you and post it here.
I was using it when I worked on a re-write instead of conversion, but they
went with conversion so I discarded it to my "use later" folder.
K will post when I get it.
Peace,
Juan
Apparently you cannot create a parametrized view using ODBC 5.1.4 (or
5) which is what I am using, it is a MySql issue.

Post by Hank
Is there any advantage to using sqlprepare() and then running sqlexec
()? versus just running sqlexec()? And I seem to remember reading
that sqlexec has a limit of 255 characters is that correct? I have
searched the help file and cannot locate where i read that.

Post by Hank
This is the code that is failing
nRetVal=3DSQLPREPARE(m.WorkingDatabase,'SELECT
userfname,userlname,ranchid FROM main_table.users; WHERE userid =3D ?
lcRanchUser AND password=3D?lcRanchPassWord', 'csrUsersOnServer')
nGoodCursor=3DSQLEXEC(nRetVal)
nRetVal returns 1
nGoodCursor returns -1
I have verified that the ?lcRanchUser and ?lcRanchPassword are in the
table. This is a MySql Database I am working with using VFP 9.0

Apparently you cannot create a parametrized view using ODBC 5.1.4 (or
5) which is what I am using, it is a MySql issue.

Post by Bernhard Sander
ned by
Bernhard,
I did and I rewrote them to reflect what the docs say, and I can get
the statement to return a cursor as long as I do not have a 'WHERE'
clause in it. As soon as I put that in, it does not return a result
set, on the MySql forums it is listed as a known bug in MySql when
using ODBC 5.1 and VFP 9. My work around (luckily it is a small data
set) is to query the table bring down the two fields I need and then
run my comparison on them locally...

Post by JayB
i think you are running into the 255 character limit of foxpro.
i always create my sql strings like this--
text to lcsql noshow textmerge
SELECT userfname,userlname,ranchid FROM main_table.users
WHERE userid like <<alltrim(lcRanchUser)>>% and
password like <<alltrim(lcRanchPassWord)>> %
endtext
=sqlexec(xx, lcsql)
or
text to lcsql noshow textmerge
SELECT userfname,userlname,ranchid FROM main_table.users
WHERE userid = ?lcRanchUser and
password =?lcRanchPassWord
endtext
=sqlexec(xx, lcsql)
i dont think you need to trim anything or use the wildcard
there are many ways to do it.
also, i would think that mysql also will use standard sql parameters in
queries, although i cannot recall if i ever done so myself.
jay

Post by Bernhard Sander
Hi Pastorhank,
Maybe you could try it with an older version of the ODBC driver.
Btw, is it a problem with the WHERE clause or a problem with these ?parameters
prefixed by a question mark?
Regards
Bernhard Sander

Post by Bernhard Sander
Hi Jay,
Hm, i think, the 255 character limit of foxpro has nothing to do with the
version of the MySql ODBC driver...
Regards
Bernhard Sander

You do not pass nRetVal from SQLPrepare into SQLExec, both SQLPrepare and
SQLExec need the same handle you create via SQLConnect or SQLStringconnect
as their first parameter. There is no sample in the VFP help suggesting or
doing what you do.
Another problem may be, that the remote database does not support your
statements as prepared statements, if they contain parameterisation.
The central point is, that SQLPrepare only helps if you execute some SQL
more than once in a row. And this only makes sense, if they can be
parameterised. Then you could also think about stored procedures.
Finally, it is totally okay to work without prepared SQL statements.
Bye, Olaf.

This way you do not have a parameterised Where clause, you prepare one
specific
where clause with this, the advantage of SQLPREPARE would not be used with
this.
When variable values change you will need to recreate the dlcSqlExec value to
reflect that.
Also this kind of approach is vulnerable for sql injection attacks, if any
of the variables
you use in there originally can come from user input.
Just think about the case of an lcRanchUser named O'Brian in above example.
...WHERE userid like 'O'Brian%' and...
The String ends after the 'O' and the result would result in a syntax error.
You may double every ', SQL Server would work that way, but that is not the
only
attack possibility here.
Bye, Olaf.

Post by Hank
eters
It did use to work with an older version of the driver.....
The problem seems to lie in the ?parameters statement which is what I
was using in the older version of a different app.
I am going to try some of the suggestions that have been make this week
and we will see what happens...
There is always an answer......

[Dan Freeman]

This is wrong.

While you can avoid the string literal problem, you don't need a memo
field and it doesn't actually do anything in this example.

Post by Roque Regalado
m.sql_str = "Select ................... from etc etc etc ....." (this can
be as long as you want)

This is untrue. It is still subject to the string literal limit.
However, you can:

Text to m.sql_str
Select .....
Endtext

*That* can be as long as you want (up to the length limit on memory
variables), without using a memo field at all.

The memo field will ONLY help you if you store stuff into a memo field
and then retrieve it, which you're not doing here and which isn't
necessary at all.

Dan

Post by Roque Regalado
You can work around the VFP 255 char limit easily by using a cursor with a
memo field as a memory variable
Sample Syntax: use this only once at the beginning of your session and keep
the cursor open during your session.
create cursor hlptxt (sql_str M)
select hlptxt
append blank
goto top
SCATTER MEMO MEMVAR
now you have a memory variable called "sql_str"
m.conn_handle = SqlConnectstring(.....)
m.sql_str = "Select ................... from etc etc etc ....." (this can
be as long as you want)
Now you can use the m.sql_str in sqlexec
SqlExec( conn_handle, m.sql_str, 'cursorname' )

Post by Jack Jackson
Use AERROR after the call fails to see what error was passed back from
the ODBC driver.
Is there really a semi-colon after the FROM clause?
SQLExec does not have a 255 character limit. VFP has a 255 limit on a
single character constant. You can concatenate smaller strings
together or use TEXT / ENDTEXT.

Post by Bernhard Sander
Hi Hank,
SqlExec() requires as first parameter the statement handle that was
returned by SqlConnect, not the return value of SqlPrepare().
m.WorkingDatabase = SqlConnect(...)
nRetVal=SQLPREPARE(m.WorkingDatabase,'SELECT ... ')
nGoodCursor=SQLEXEC(m.WorkingDatabase)
Reread the examples of the help file at the respective topics
Regards
Bernhard Sander

Post by Richard Stecenko
How do you pass the value of the parameters to MySQL?
store "SELECT userfname,userlname,ranchid FROM main_table.users " +;
"WHERE userid like '" + alltrim(lcRanchUser) +"%' and ";
"password like '" +alltrim(lcRanchPassWord) +"%'" to dlcSqlExec
then either exec or prepare and execute.
For passwords and user names, I'd probably not use the % wild card,
but that is just an example.
Richard Stecenko
Interactive Computer Services Inc.
Winnipeg, Canada
204.453.2052

Post by Juan Alonso
Hank,
You can create any kind of parameterized view, especially using
SQL-PassThrough.
I use SQLEXEC() when I do mine and it works fine. I pass information to
my app for customer info, invoice data and inventory data without any
problems.
I can tell you though that you have to use other SQL-PassThrough
functions that help to define the use of the fields from the table.
Let me see if I can get that code for you and post it here.
I was using it when I worked on a re-write instead of conversion, but
they went with conversion so I discarded it to my "use later" folder.
K will post when I get it.
Peace,
Juan
Apparently you cannot create a parametrized view using ODBC 5.1.4 (or
5) which is what I am using, it is a MySql issue.

Post by Hank
Is there any advantage to using sqlprepare() and then running sqlexec
()? versus just running sqlexec()? And I seem to remember reading
that sqlexec has a limit of 255 characters is that correct? I have
searched the help file and cannot locate where i read that.

Post by Hank
This is the code that is failing
nRetVal=3DSQLPREPARE(m.WorkingDatabase,'SELECT
userfname,userlname,ranchid FROM main_table.users; WHERE userid =3D ?
lcRanchUser AND password=3D?lcRanchPassWord', 'csrUsersOnServer')
nGoodCursor=3DSQLEXEC(nRetVal)
nRetVal returns 1
nGoodCursor returns -1
I have verified that the ?lcRanchUser and ?lcRanchPassword are in the
table. This is a MySql Database I am working with using VFP 9.0

Post by Juan Alonso
Apparently you cannot create a parametrized view using ODBC 5.1.4 (or
5) which is what I am using, it is a MySql issue.

Post by Bernhard Sander
ned by
Bernhard,
I did and I rewrote them to reflect what the docs say, and I can get
the statement to return a cursor as long as I do not have a 'WHERE'
clause in it. As soon as I put that in, it does not return a result
set, on the MySql forums it is listed as a known bug in MySql when
using ODBC 5.1 and VFP 9. My work around (luckily it is a small data
set) is to query the table bring down the two fields I need and then
run my comparison on them locally...

Post by JayB
i think you are running into the 255 character limit of foxpro.
i always create my sql strings like this--
text to lcsql noshow textmerge
SELECT userfname,userlname,ranchid FROM main_table.users
WHERE userid like <<alltrim(lcRanchUser)>>% and
password like <<alltrim(lcRanchPassWord)>> %
endtext
=sqlexec(xx, lcsql)
or
text to lcsql noshow textmerge
SELECT userfname,userlname,ranchid FROM main_table.users
WHERE userid = ?lcRanchUser and
password =?lcRanchPassWord
endtext
=sqlexec(xx, lcsql)
i dont think you need to trim anything or use the wildcard
there are many ways to do it.
also, i would think that mysql also will use standard sql parameters
in queries, although i cannot recall if i ever done so myself.
jay

Post by Bernhard Sander
Hi Pastorhank,
Maybe you could try it with an older version of the ODBC driver.
Btw, is it a problem with the WHERE clause or a problem with these
?parameters prefixed by a question mark?
Regards
Bernhard Sander

Post by Bernhard Sander
Hi Jay,
Hm, i think, the 255 character limit of foxpro has nothing to do
with the version of the MySql ODBC driver...
Regards
Bernhard Sander

You do not pass nRetVal from SQLPrepare into SQLExec, both
SQLPrepare and SQLExec need the same handle you create via
SQLConnect or SQLStringconnect as their first parameter. There is
no sample in the VFP help suggesting or doing what you do.
Another problem may be, that the remote database does not support
your statements as prepared statements, if they contain
parameterisation.
The central point is, that SQLPrepare only helps if you execute
some SQL more than once in a row. And this only makes sense, if
they can be parameterised. Then you could also think about stored
procedures.
Finally, it is totally okay to work without prepared SQL
statements.
Bye, Olaf.

This way you do not have a parameterised Where clause, you
prepare one specific
where clause with this, the advantage of SQLPREPARE would not be
used with this.
When variable values change you will need to recreate the
dlcSqlExec value to reflect that.
Also this kind of approach is vulnerable for sql injection
attacks, if any of the variables
you use in there originally can come from user input.
Just think about the case of an lcRanchUser named O'Brian in
above example.
...WHERE userid like 'O'Brian%' and...
The String ends after the 'O' and the result would result in a
syntax error.
You may double every ', SQL Server would work that way, but that
is not the only
attack possibility here.
Bye, Olaf.

Post by Hank
eters
It did use to work with an older version of the driver.....
The problem seems to lie in the ?parameters statement which is
what I was using in the older version of a different app.
I am going to try some of the suggestions that have been make
this week and we will see what happens...
There is always an answer......

[Olaf Doschke]

Post by Richard Stecenko
store "SELECT userfname,userlname,ranchid FROM main_table.users " +;
"WHERE userid like '" + alltrim(lcRanchUser) +"%' and ";
"password like '" +alltrim(lcRanchPassWord) +"%'" to dlcSqlExec

This way you don't have a parameterised Where clause, you prepare one
specific
where clause with this, the advantage of SQLPREPARE would not be used with
this.
When variable values change you'll need to recreate the dlcSqlExec value to
reflect that.

Also this kind of approach is vulnerable for sql injection attacks, if any
of the variables
you use in there originally can come from user input.

Just think about the case of an lcRanchUser named O'Brian in above example.

That results in noworking SQL:


...WHERE userid like 'O'Brian%' and...

The String ends after the 'O' and the result would result in a syntax error.

You may double every ', SQL Server would work that way, but that's not the
only
attack possibility here.

Bye, Olaf.

[Bernhard Sander]

Hi Pastorhank,

Post by Pastorhank
I did and I rewrote them to reflect what the docs say, and I can get
the statement to return a cursor as long as I don't have a 'WHERE'
clause in it. As soon as I put that in, it doesn't return a result
set, on the MySql forums it's listed as a known bug in MySql when
using ODBC 5.1 and VFP 9. My work around (luckily it's a small data
set) is to query the table bring down the two fields I need and then
run my comparison on them locally...

Maybe you could try it with an older version of the ODBC driver.

Btw, is it a problem with the WHERE clause or a problem with these ?parameters
prefixed by a question mark?

Regards
Bernhard Sander

[Hank]

Post by Bernhard Sander
Hi Pastorhank,

Post by Pastorhank
I did and I rewrote them to reflect what the docs say, and I can get
the statement to return a cursor as long as I don't have a 'WHERE'
clause in it.  As soon as I put that in, it doesn't return a result
set, on the MySql forums it's listed as a known bug in MySql when
using ODBC 5.1 and VFP 9.  My work around (luckily it's a small data
set) is to query the table bring down the two fields I need and then
run my comparison on them locally...

Maybe you could try it with an older version of the ODBC driver.
Btw, is it a problem with the WHERE clause or a problem with these ?parameters
prefixed by a question mark?
Regards
Bernhard Sander

It did use to work with an older version of the driver.....

The problem seems to lie in the ?parameters statement which is what I
was using in the older version of a different app.

I'm going to try some of the suggestions that have been make this week
and we'll see what happens...

There's always an answer......

[Olaf Doschke]

Post by Hank
This is the code that is failing
nRetVal=SQLPREPARE(m.WorkingDatabase,'SELECT
userfname,userlname,ranchid FROM main_table.users; WHERE userid = ?
lcRanchUser AND password=?lcRanchPassWord', 'csrUsersOnServer')
nGoodCursor=SQLEXEC(nRetVal)

You don't pass nRetVal from SQLPrepare into SQLExec, both SQLPrepare and
SQLExec need the same handle you create via SQLConnect or SQLStringconnect
as their first parameter. There is no sample in the VFP help suggesting or
doing what you do.

Another problem may be, that the remote database does not support your
statements as prepared statements, if they contain parameterisation.

The central point is, that SQLPrepare only helps if you execute some SQL
more than once in a row. And this only makes sense, if they can be
parameterised. Then you could also think about stored procedures.

Finally, it's totally okay to work without prepared SQL statements.

Bye, Olaf.