svn export is a terrible way to update live site.

- slow link or large website: svn export will take a long time, your users will love you
- certain apps will kill user sessions on code reload. Specifically I am looking at you Microsoft, with your global.asa / global.asx (out of open source PHP seems best. Not sure how Django/RoR enjoy code changes to pages that are already running)

Best setup I am aware of:

Point your website to something like ../[website]/live
Checkout your website to ../[website]/checkout
run remote svn udpate: ssh [server] -p [port] -u [user] svn update ../[website]/checkout
trick: you can force export from checked out folder
run remote svn export: ssh [server] -p [port] -u [user] svn export ../[website]/checkout ../[website]/r[evision]
note: you export to a new folder, that is marked explicitly as specific revision number
symlink ../[website]/live into latest ../[website]/r[evision]
trick: this way, if website gets broken, you change symlink to revert to a known stable version

This is safe on bandwidth (svn checkout between servers), fast atomic upgrade on the server (since symlink is changed once export is completed).

SELECT * FROM myData WHERE CONTAINS (column, 'FORMSOF (INFLECTIONAL, ?)')

Parameters are intended for user input. I certainly hoping you aren't allowing users to type functions in directly...

For one of the servers I worked on this was the syntax for full text search. you would do CONTAINS ( column , param ) . The argument param was a string that contained additional properties for the full text search engine. One could add things like weights associated with words and phrases (hence double quotes), or ask to search for word variation (search for 'good' also matches 'best', since they are related). Ofcourse, this was all happening in one string, that param, so you had to, yet again, format your own string.

I am not advocating against using parametered sql calls, actually they are great, but I fear that on some level they are not much better than the magic_quotes=on, I fear as if they were an escape for lazy developers : use always, and your code will be unhackable. That was the premise of magic_quotes, it made developers feel safe, as if magically their code was unbreakable.

Now, for stored procedure calls, especially with parameters that double as both input and ouput, the parameter binding is the only way to go.

Cheers