>>>No, VFP always checks inside the exe/app first. Btw, your solution sounds like a perfect description of how NOT to do things since a user can easily do anything with the data....! Have you ever heard of SQL injection?
>>>
>>>>I have an app that includes a reporting module; this runs "external" queries and reports - that is, they are not compiled into my app. So for example my reporting module might call c:\localQueries\query1.prg to generate a cursor and then c:\localReports\report1.frx to report on the data. If my compiled app also includes a prg called "query1", at run time this gets called in preference to the external query - despite me calling the external prg with a fully qualified path name. Is there some way to avoid this - other than making sure the external queries are all named differently to any prgs compiled into the app.
>>>>
>>>>Thanks in advance
>>>>Barry Sutton
>>
>>Hi Tore
>>
>>SQL Injection is only possible when a database server is executing queries. It also requires an inexperienced programmer to construct SQL by concatenating user values into the command string to be executed, instead of sending user values as parameters.
>
>It's also possible against DBFs.

Could you give an example?

The only way I know to make vfp *simulate* a SQL Injection Attack might be:

lcUserEntry = thisform.sometextbox.value
lcSQL = 'select * from sometable where somefield = " ' + m.lcUserEntry + ' " '
Execscript(m.lcSQL)

The user entry might be

" < alt+013 >< alt+010 >SELECT sometable< alt+013 >< alt+010 >SET SAFETY OFF< alt+013 >< alt+010 >ZAP< alt+013 >< alt+010 >*

Had the lcSQL line been this:

lcSQL = 'select * from sometable where somefield = m.lcUserEntry'

and if lcUserEntry was private, then the sql command would effectively be parameterized. The execscript would not execute the content of lcUserEntry. That's why it's called SQL Injection. The content of a variable is injected into an SQL command.