On 04/12/14 07:16 AM, Jonas Maebe wrote:
The closest equivalent is probably sysutils.UnicodeCompareText(). It
uses CompareStringW on Windows though, and on Unix it converts both
strings to uppercase, locale-sensitive-wise, and compares those.
As a general rule it is better to convert to lowe
On 25/11/14 03:47 AM, Michael Van Canneyt wrote:
On Mon, 24 Nov 2014, Chris Dryburgh wrote:
Found this bug report from 2010 on using implicit transactions in
PostgreSQL. As far as I can tell nothing has happened since. Using
the TSQLTransaction.Action setting looks like a good approach to
Found this bug report from 2010 on using implicit transactions in
PostgreSQL. As far as I can tell nothing has happened since. Using the
TSQLTransaction.Action setting looks like a good approach to
implementing implicit transactions. It would mean warning users about
setting action as it curren
On 06/11/14 10:22 AM, Martin Schreiber wrote:
On Thursday 06 November 2014 15:43:03 Chris Dryburgh wrote:
I understand that but I don't think your approach allows for a series of
read-only queries to be run in a single transaction batch.
Why not? Activate the datasets with dso_offline
On 06/11/14 01:31 AM, Martin Schreiber wrote:
On Wednesday 05 November 2014 19:19:41 Chris Dryburgh wrote:
[...]> run together. It is also read-only transaction idiot proof which is a
good thing. Michael's approach of allowing for closing a transaction
without closing a still in use
On 05/11/14 05:03 AM, Mark Morgan Lloyd wrote:
Michael Van Canneyt wrote:
On Tue, 4 Nov 2014, Chris Dryburgh wrote:
Hi
In PostgreSQL it is considered poor practice to have long running
idle transactions.
https://encrypted.google.com/#q=postgresql+idle+in+transaction
This is a known
On 05/11/14 03:04 AM, Martin Schreiber wrote:
On Tuesday 04 November 2014 19:33:22 Chris Dryburgh wrote:
The end result should be that server transactions only open when needed.
Users would likely commit write transactions quickly to save data to the
database. Read-only transactions might be
Hi
In PostgreSQL it is considered poor practice to have long running idle
transactions.
https://encrypted.google.com/#q=postgresql+idle+in+transaction
Long running idle transactions are common with SQLdb and PostgreSQL. In
FPC 2.6.4 and I think the development version a open connection has a
