View Issue Details

IDProjectCategoryView StatusLast Update
0031231FPCDatabasepublic2020-11-14 00:35
ReporterHolger Klemt Assigned ToMichael Van Canneyt  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformWindows 
Target Version4.0.0Fixed in Version3.3.1 
Summary0031231: procedure TCustomSQLQuery.Prepare does not work
Descriptionat 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 Reproducesee 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 Informationthis 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;
TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget3.2.2
Attached Files

Relationships

related to 0033025 resolvedMichael Van Canneyt [fcl-db] An SQL statement is always prepared in open/close loop even if the SQL doesn't change 
related to 0037645 resolvedMichael Van Canneyt SqlDb: Calling TSQLQuery.Prepare directly, opening, closing and re opening does not work with IBConnection 

Activities

Holger Klemt

2017-01-15 02:10

reporter  

prepare.7z (91,548 bytes)

Michl

2017-03-05 18:54

reporter   ~0098665

This is a FPC issue. Can someone move it to FPC?!

Joost van der Sluis

2019-12-18 15:56

manager   ~0119913

This has not been solved. Michaels 'fix' has several flaws that needs addressing. That's why I've opened the bug again.

Michael Van Canneyt

2020-11-14 00:35

administrator   ~0126904

Fixed properly this time, see related bugreport 37645

Issue History

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
2020-11-14 00:34 Michael Van Canneyt Relationship added related to 0037645
2020-11-14 00:35 Michael Van Canneyt Assigned To Joost van der Sluis => Michael Van Canneyt
2020-11-14 00:35 Michael Van Canneyt Status confirmed => resolved
2020-11-14 00:35 Michael Van Canneyt Resolution open => fixed
2020-11-14 00:35 Michael Van Canneyt FPCTarget 4.0.0 => 3.2.2
2020-11-14 00:35 Michael Van Canneyt Note Added: 0126904