From efdc0adc20ff60b9b9151a578fa9c9124688743f Mon Sep 17 00:00:00 2001
From: Johannes Hoermann <j.hoermann@adito.de>
Date: Tue, 29 Oct 2019 15:08:27 +0100
Subject: [PATCH] Sql Lib docu kleines refactoring
---
process/Sql_lib/documentation.adoc | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/process/Sql_lib/documentation.adoc b/process/Sql_lib/documentation.adoc
index ba5d6eb3c4..a036b8325e 100644
--- a/process/Sql_lib/documentation.adoc
+++ b/process/Sql_lib/documentation.adoc
@@ -28,11 +28,10 @@ The tests included in the library SqlLib_tests use the UnitTest_lib for unit tes
The SQL builder applies Prepared Statements (if used correctly). These should *always* be used for reasons of
-* *Security* (prevention of "SQL injection" see also `AID068`):
-This is the *most important* aspect.
+* *Security* (main benefit):
In SQL statements like
`"select * from PERSON where FIRSTNAME = '" + userInput + "'"`
-the user could input also any - possibly harmful - SQL code. This will be avoided by using Prepared Statements: Even if you just select for IDs, the security and the quality of your code will be much higher. Because you are used to using Prepared Statements and won't forget them when they are really needed. (e.g. direct user input)
+the user could input also any - possibly harmful - SQL code ("SQL injection" see also `AID068`). This will be avoided by using Prepared Statements: Even if you just select for IDs, the security and the quality of your code will be much higher. Because you are used to using Prepared Statements and won't forget them when they are really needed. (e.g. direct user input)
* *Speed*: If the server executes a Prepared Statement, the performance will, in many cases, be higher compared to executing a self-made SQL code.
=== Usability
--
GitLab