Re: DBD::Sqlite queries slow - and gives wrong results

in reply to DBD::Sqlite queries slow - and gives wrong results

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re^2: DBD::Sqlite queries slow - and gives wrong results by Your Mother (Archbishop) on Dec 12, 2017 at 05:31 UTC
You side-stepped the OP's question, predictably. NetWallah managed to make an interesting and helpful technical suggestion even without having an answer to the problem. Could you please cite the SQLite documentation which suggests the wisdom of using transactions for `SELECT` statements? Barring that, please provide benchmark code supporting your position that it is a best practice. COGTFO®	[reply] [d/l]
Re^2: DBD::Sqlite queries slow - and gives wrong results by herveus (Prior) on Dec 12, 2017 at 18:45 UTC
Howdy! First, "citation needed", because you are making wild claims with no supporting evidence. A select requires a SHARED lock, and that is done via a transaction. If you have multiple select statements that you want to ensure all read the same set of data, wrap them in a transaction. Also to reduce locking overhead. What is the actual relevance of the lack of a "SQL server"? What do you mean by that? The SQLite engine does its thing just as any other RDBMS engine does, but not as a persistent external process. That has nothing to do with all of the italicized and scare-quoted phrases your imprecation is larded with. And, on top of that, what relevance does your prescription have to the actual question at hand? You rail about something without explaining how it matters. So, your closing remark is, on its face, incorrect, as it appears that no actual help was provided. Please stop. yours, Michael	[reply]
Re^2: DBD::Sqlite queries slow - and gives wrong results - HEADWHACK by erix (Prior) on Dec 13, 2017 at 11:20 UTC
Short-Answer: Do This Now: “Bracket all of your SQLite calls, whether(!) read or write, in transactions.” He's already using transactions; see the connection parameter 'AutoCommit=>0' or TIAS: `$ perl -MDBI -e 'my$d=DBI->connect("dbi:SQLite:dbname=x.db","","",{Aut +oCommit=>0}); $d->begin_work or die "ah, of course! HEADWHACK\n"' DBD::SQLite::db begin_work failed: Already in a transaction at -e line + 1. ah, of course! HEADWACK` [download]	[reply] [d/l]
Re^2: DBD::Sqlite queries slow - and gives wrong results by marto (Cardinal) on Dec 12, 2017 at 10:42 UTC
“Personally been there. Personally whacked my head against that.” I wonder if this could be contributing to the nonsense continually pollute this site with?	[reply]
Re^2: DBD::Sqlite queries slow - and gives wrong results by eyepopslikeamosquito (Archbishop) on Dec 13, 2017 at 22:09 UTC
Short-Answer: Do This Now: Pick up all “SQL manuals” on your “desk” `...` whether small or *big*(!) Personally whack your head against them HTH™ ...	[reply] [d/l]
Re^2: DBD::Sqlite queries slow - and gives wrong results by Anonymous Monk on Dec 11, 2017 at 23:17 UTC
it will physically verify every write the same BS youve been repeating for years even after you were proven wrong. troll	[reply]

In Section Seekers of Perl Wisdom