| … | |
… | |
| 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. |
