… | |
… | |
69 | =over 4 |
69 | =over 4 |
70 | |
70 | |
71 | =item $sql_exec |
71 | =item $sql_exec |
72 | |
72 | |
73 | Since the C<sql_exec> family of functions return a statement handle there |
73 | Since the C<sql_exec> family of functions return a statement handle there |
74 | must eb another way to test the return value of the C<execute> call. This |
74 | must be another way to test the return value of the C<execute> call. This |
75 | global variable contains the result of the most recent call to C<execute> |
75 | global variable contains the result of the most recent call to C<execute> |
76 | done by this module. |
76 | done by this module. |
77 | |
77 | |
78 | =item $PApp::SQL::DBH |
78 | =item $PApp::SQL::DBH |
79 | |
79 | |
… | |
… | |
111 | __LINE__ work fine as well). |
111 | __LINE__ work fine as well). |
112 | |
112 | |
113 | The reason C<$id> is necessary is that you might specify special connect |
113 | The reason C<$id> is necessary is that you might specify special connect |
114 | arguments or special flags, or you might want to configure your $DBH |
114 | arguments or special flags, or you might want to configure your $DBH |
115 | differently than maybe other applications requesting the same database |
115 | differently than maybe other applications requesting the same database |
116 | connection. If none of this is becessary for your application you can |
116 | connection. If none of this is necessary for your application you can |
117 | leave $id empty (i.e. ""). |
117 | leave C<$id> empty (i.e. ""). |
118 | |
118 | |
119 | If specified, C<$connect> is a callback (e.g. a coderef) that will be |
119 | If specified, C<$connect> is a callback (e.g. a coderef) that will be |
120 | called each time a new connection is being established, with the new |
120 | called each time a new connection is being established, with the new |
121 | C<$dbh> as first argument. |
121 | C<$dbh> as first argument. |
122 | |
122 | |
… | |
… | |
163 | statement handle. The command and the statement handle will be cached |
163 | statement handle. The command and the statement handle will be cached |
164 | (with the database handle and the sql string as key), so prepare will be |
164 | (with the database handle and the sql string as key), so prepare will be |
165 | called only once for each distinct sql call (please keep in mind that the |
165 | called only once for each distinct sql call (please keep in mind that the |
166 | returned statement will always be the same, so, if you call C<sql_exec> |
166 | returned statement will always be the same, so, if you call C<sql_exec> |
167 | with the same dbh and sql-statement twice (e.g. in a subroutine you |
167 | with the same dbh and sql-statement twice (e.g. in a subroutine you |
168 | called), the statement handle for the first call mustn't be used. |
168 | called), the statement handle for the first call mustn't not be in use |
|
|
169 | anymore, as the subsequent call will re-use the handle. |
169 | |
170 | |
170 | The database handle (the first argument) is optional. If it is missing, |
171 | The database handle (the first argument) is optional. If it is missing, |
171 | C<sql_exec> first tries to use the variable C<$DBH> in the current (= |
172 | C<sql_exec> first tries to use the variable C<$DBH> in the current (= |
172 | calling) package and, if that fails, it tries to use database handle in |
173 | calling) package and, if that fails, it tries to use database handle in |
173 | C<$PApp::SQL::DBH>, which you can set before calling these functions. |
174 | C<$PApp::SQL::DBH>, which you can set before calling these functions. |