View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0031231 | FPC | Database | public | 2017-01-15 02:10 | 2019-12-18 16:01 |
| Reporter | Holger Klemt | Assigned To | Joost van der Sluis | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Platform | Windows | OS | OS Version | ||
| Product Version | Product Build | ||||
| Target Version | 4.0.0 | Fixed in Version | 3.3.1 | ||
| Summary | 0031231: procedure TCustomSQLQuery.Prepare does not work | ||||
| Description | at least on Firebird, a prepared query saves a lot of time when the same sql text is executed with changed parameters multiple times. Calling prepare and unprepare does not work as expected, since anytime a query is closed, an unprepare is done. | ||||
| Steps To Reproduce | see attached example, i added sqldb.pas and ibconnection.pas in the directory to make debugging, test changes and breakpoints easier to be set. in the example the statement id is taken from mon$statements, if prepapre works fine, there should be not 100 as a result, 1 (or 2 incl first stement) would be the expected result. | ||||
| Additional Information | this procedure in sqldb seems to not recognize the correct info if manual prepare was called an always initiates unprepare, visible also in fb25/fb30 in traceapi . procedure TCustomSQLQuery.SetActive(Value: Boolean); begin inherited SetActive(Value); // The query is UnPrepared, so that if a transaction closes all datasets // they also get unprepared if not Value and IsPrepared then UnPrepare; end; | ||||
| Tags | No tags attached. | ||||
| Fixed in Revision | |||||
| FPCOldBugId | |||||
| FPCTarget | 4.0.0 | ||||
| Attached Files |
| ||||
| related to | 0033025 | resolved | Michael Van Canneyt | [fcl-db] An SQL statement is always prepared in open/close loop even if the SQL doesn't change |
|
|
prepare.7z (91,548 bytes) |
|
|
This is a FPC issue. Can someone move it to FPC?! |
|
|
This has not been solved. Michaels 'fix' has several flaws that needs addressing. That's why I've opened the bug again. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-01-15 02:10 | Holger Klemt | New Issue | |
| 2017-01-15 02:10 | Holger Klemt | File Added: prepare.7z | |
| 2017-03-05 18:54 | Michl | Note Added: 0098665 | |
| 2019-11-30 11:59 | Joost van der Sluis | Project | Lazarus => FPC |
| 2019-11-30 13:44 | Joost van der Sluis | Relationship added | related to 0033025 |
| 2019-11-30 15:35 | Joost van der Sluis | Assigned To | => Joost van der Sluis |
| 2019-11-30 15:35 | Joost van der Sluis | Status | new => assigned |
| 2019-12-06 11:08 | Michael Van Canneyt | Assigned To | Joost van der Sluis => Michael Van Canneyt |
| 2019-12-06 11:08 | Michael Van Canneyt | Status | assigned => resolved |
| 2019-12-06 11:08 | Michael Van Canneyt | Resolution | open => duplicate |
| 2019-12-06 11:08 | Michael Van Canneyt | Fixed in Version | => 3.3.1 |
| 2019-12-06 11:08 | Michael Van Canneyt | FPCTarget | => 3.2.0 |
| 2019-12-06 11:13 | Michael Van Canneyt | Product Version | 1.6.2 => |
| 2019-12-06 11:13 | Michael Van Canneyt | Target Version | => 4.0.0 |
| 2019-12-06 11:13 | Michael Van Canneyt | FPCTarget | 3.2.0 => 4.0.0 |
| 2019-12-18 15:52 | Joost van der Sluis | Assigned To | Michael Van Canneyt => Joost van der Sluis |
| 2019-12-18 15:52 | Joost van der Sluis | Status | resolved => confirmed |
| 2019-12-18 15:56 | Joost van der Sluis | Note Added: 0119913 | |
| 2019-12-18 16:01 | Joost van der Sluis | Resolution | duplicate => open |
