brian, made this for year without any problems. also good for beginners.
checking for proper values and a corerct sql syntax should be always done even when parameterized.
BrianH
Nice to hear, TomBon. Nonetheless, such checking is exactly what parameterized queries do, and I often have to fix errors made by other developers who don't use them. Plus, parameterized queries are a lot quicker on most databases because the query plan gets cached.
It is always a bad idea to suggest to newbie programmers that they not use parameterized queries.
TomBon
well better first to make him clear whats going up, then make the final. I think he is confused by this examples. btw, how parameterized queries preventing sql injection if not serverside?
BrianH
Non-parameterized queries are an advanced topic for experienced developers, though also the subject of the worst coding horror stories :)
TomBon
well, well :)
but let's first try to help afsan, if his script is running he can improve it.
afsanehsamim
guys ...i am happy :) it is working... tnx a lot Andreas ...
thank you TomBon and BrianH
TomBon
nice, good luck with your crossword afsan...
BrianH
With parameterized queries (even in REBOL) the SQL and the parameters are sent separately and combined in the server. The query plan is generated only once per query, with the parameter placeholders being in the plan. Then the actual parameters are plugged into the plan. The next time the parameterized query is called (maybe with differe3nt parameter values) the same plan is used and the new parameter values are plugged in.
TomBon
isn't this execution optimation?. in this case a stored procedure will help also. how will this prevent from sql injection? compared to a concatenated server side sql string?
BrianH
If you build a query dynamically with rejoin or something, the query is put together client side and then the server has to generate a new query plan for each distinct set of parameter values. This takes time and blows the query plan cache, which slows down the whole query process.
The problem is that your ad-hoc parameter screening is usually not perfect. Parameterized queries don't build a query in the server, they just plug in the values to an already-compiled query (the "query plan"). The server doesn't have to do any parameter screening other than for malformed values in the protocol.
TomBon
depends on the needs. I always try to detach the data sink from input logic. this way you can change your db backend very easy but of course everybody has it's own style in this.
BrianH
For new developers ad-hoc parameter screening is even more likely to be bad (and most that don't use parameterized queries are still new, no matter how long they've been programming, because parameterized queries are almost always inherently better). Even if it wasn't a safety issue, they're a lot faster.
I've seen data front-ends that don't use parametrized queries when talking to SQL servers that support them. They need work.
afsanehsamim
could you tell me how can i compare values of two tables in database?
Endo
About parametrized queries: The only problem using them on R2, at least with RT's default ODBC, there is no chance to use NULL values. None of those work: insert db-port ["INSERT t (a) VALUES (?)" NULL] insert db-port ["INSERT t (a) VALUES (?)" 'NULL] insert db-port ["INSERT t (a) VALUES (?)" "NULL"] insert db-port ["INSERT t (a) VALUES (?)" none] insert db-port reduce ["INSERT t (a) VALUES (?)" none]
TomBon
you have more than one solution, the first is a simple serial SELECT on each table -> compare the output for equal. of course this produce unnecessary DB overhead but I guess you won't feel any speed difference except you are serving a whole city concurrently. another, better one is a JOIN or UNION.
SELECT table_name1.column_name(s), ... FROM table_name1 LEFT JOIN table_name2 ON table_name1.column_name=table_name2.column_name
the JOIN direction (LEFT,RIGHT,INNER) for your reference table is important here. the resultset is a table containing BOTH columns. if both having a value -> match, if one is empty then you don't.
index both fields to accelerate the query and use something like the free SQLyog to test different queries to make debugging easier for you.
while you situation reminds me to myself, sitting infront of a monochrom asthon tate dot some decades ago and asking what next?, you should 'bite' yourself now thru the rest. It won't help you on longterm if you don't.