in reply to Re^2: Preventing malicious T-SQL injection attacks
in thread Preventing malicious T-SQL injection attacks

Yes, for example, it means programmers can't go issuing any SQL they like from the client programs but have to put all SQL in stored procedures and execute it with parameters determined at the client end. One source of this strategy was back in the heyday of C++ in the 1990s when programmers (with usually more C knowledge than database knowledge) were apt to embed all SQL in their client programs which then tended to cause objects to deadlock each other and even themselves in some cases and also to prevent unecessary communication across the network. Rather than have a client program sending SQL requests results and getting sometimes huge result sets over the net and then processing them, it is more efficient overall to let the client program handle the client functionality and stored procedures handle the server functionality - but there are many people out there who want to be able to code everything from the only language they know and that is a tendency especially we as Perl programmers with all our many modules also need to avoid sometimes.


Free your mind