Joost van der Sluis wrote:
Since this is strictly read-only, I can't see why I need transactions,
but I obviously respect the judgment of whoever designed the architecture.
Well, you always need a transaction. Without a transaction, Postgres
will do nothing, ever.
I assume you are used to
On Fri, 10 Dec 2010, Mark Morgan Lloyd wrote:
Joost van der Sluis wrote:
Since this is strictly read-only, I can't see why I need transactions, but
I obviously respect the judgment of whoever designed the architecture.
Well, you always need a transaction. Without a transaction, Postgres
Michael Van Canneyt wrote:
Well, you always need a transaction. Without a transaction, Postgres
will do nothing, ever.
I assume you are used to the fact that postgres automatically creates an
transaction for you. With Sqldb you have to do this yourself.
Please excuse me for threading onto a
On Fri, 10 Dec 2010, Mark Morgan Lloyd wrote:
Michael Van Canneyt wrote:
Well, you always need a transaction. Without a transaction, Postgres
will do nothing, ever.
I assume you are used to the fact that postgres automatically creates an
transaction for you. With Sqldb you have to do this
zel...@holobit.net wrote:
Would it be possible to write a server-side PostgreSQL extension using
Lazarus, including friendly debugging?
Yes, feel free to do that :)
[GRIN] Actually, it was a serious question: can Lazarus debug a .so and
would it stand any chance of debugging one which had
On Thu, 2 Dec 2010, Mark Morgan Lloyd wrote:
zel...@holobit.net wrote:
Would it be possible to write a server-side PostgreSQL extension using
Lazarus, including friendly debugging?
Yes, feel free to do that :)
[GRIN] Actually, it was a serious question: can Lazarus debug a .so and
would
michael.vancann...@wisa.be wrote:
Would it be possible to write a server-side PostgreSQL extension
using
Lazarus, including friendly debugging?
Yes, feel free to do that :)
[GRIN] Actually, it was a serious question: can Lazarus debug a .so and
would it stand any chance of debugging one
On Thursday, 2. December 2010 14.14:17 Mark Morgan Lloyd wrote:
GDB has a command for it (attach) , so it should be possible.
Potentially doable rather than currently possible. Presumably it would
be a functional alternative to the Run button or equivalent menu entry.
MSEide has
Martin Schreiber wrote:
On Thursday, 2. December 2010 14.14:17 Mark Morgan Lloyd wrote:
GDB has a command for it (attach) , so it should be possible.
Potentially doable rather than currently possible. Presumably it would
be a functional alternative to the Run button or equivalent menu entry.
On Wed, 2010-12-01 at 14:17 +0100, zeljko wrote:
On Wednesday 01 December 2010 13:48, Joost van der Sluis wrote:
On Tue, 2010-11-30 at 13:14 +0100, zeljko wrote:
I think we should not change a thing, until the problem is clear. Maybe
we can come up with some 'general'
On Wednesday 01 December 2010 14:23, Joost van der Sluis wrote:
On Wed, 2010-12-01 at 14:17 +0100, zeljko wrote:
On Wednesday 01 December 2010 13:48, Joost van der Sluis wrote:
On Tue, 2010-11-30 at 13:14 +0100, zeljko wrote:
I think we should not change a thing, until the problem is
Joost van der Sluis wrote:
Is there somewhere I can hook into the TSQLQuery to (a) see exactly what
query was passed to the server (b) collect any error text and (c) get
execution timing?
a) Easiest is to use the database-client's log mechanism. (If there is
any). Else you can change the
On Wed, 1 Dec 2010, Joost van der Sluis wrote:
Is there somewhere I can hook into the TSQLQuery to (a) see exactly what
query was passed to the server (b) collect any error text and (c) get
execution timing?
a) Easiest is to use the database-client's log mechanism. (If there is
any). Else
On Wed, 2010-12-01 at 16:01 +0100, michael.vancann...@wisa.be wrote:
On Wed, 1 Dec 2010, Joost van der Sluis wrote:
Is there somewhere I can hook into the TSQLQuery to (a) see exactly what
query was passed to the server (b) collect any error text and (c) get
execution timing?
a)
michael.vancann...@wisa.be wrote:
On Wed, 1 Dec 2010, Joost van der Sluis wrote:
Is there somewhere I can hook into the TSQLQuery to (a) see exactly what
query was passed to the server (b) collect any error text and (c) get
execution timing?
a) Easiest is to use the database-client's log
zeljko wrote:
Well, these are tne ansi/sql transacion isolation levels. do you know a
database which actually uses/supports these? (Except from Oracle)
Yes, PostgreSQL supports all of them.
With the same names? I know from some other db-servers, that they use
Yes.
Joost van der Sluis wrote:
I am a firm proponent of putting a unified mechanism for a) and c) in
TSQLQuery/TSQLConnection, and have, in fact, a patch ready for this
(it implements a simple event mechanism for the log).
That's a no-brainer. It could als use TCustomApplication.Log, if
On Wed, 1 Dec 2010, Joost van der Sluis wrote:
On Wed, 2010-12-01 at 16:01 +0100, michael.vancann...@wisa.be wrote:
On Wed, 1 Dec 2010, Joost van der Sluis wrote:
Is there somewhere I can hook into the TSQLQuery to (a) see exactly what
query was passed to the server (b) collect any
zel...@holobit.net wrote:
Quoting Mark Morgan Lloyd markmll.laza...@telemetry.co.uk:
Would it be possible to write a server-side PostgreSQL extension using
Lazarus, including friendly debugging?
Yes, feel free to do that :)
[GRIN] Actually, it was a serious question: can Lazarus debug a
En/na Joost van der Sluis ha escrit:
This can be done perfectly with sqldb. But which are the cases which are
difficult?
When you have a visual database component (e.g. a dbgrid) that needs the
connection opened all the time (otherwise it wouldn't show any data) and
locks the database for
On Tue, 2010-11-30 at 09:16 +0100, Luca Olivetti wrote:
En/na Joost van der Sluis ha escrit:
This can be done perfectly with sqldb. But which are the cases which are
difficult?
When you have a visual database component (e.g. a dbgrid) that needs the
connection opened all the time
On Mon, 2010-11-29 at 17:57 +0100, michael.vancann...@wisa.be wrote:
On Mon, 29 Nov 2010, Joost van der Sluis wrote:
On Wed, 2010-11-24 at 20:57 +0100, Michael Van Canneyt wrote:
On Wed, 24 Nov 2010, Alexsander Rosa wrote:
But it is transparent to the libpq programmer; why it's not
On Tue, 2010-11-30 at 07:29 +, Mark Morgan Lloyd wrote:
Joost van der Sluis wrote:
PostgreSQL gets locked, I mean, the tables being used by sqldb can't
be modified (new columns, new constraints, etc) while the sqldb
connection is active, even if it's a read-only SELECT. If someone is
On Tue, 30 Nov 2010, Joost van der Sluis wrote:
On Mon, 2010-11-29 at 17:57 +0100, michael.vancann...@wisa.be wrote:
On Mon, 29 Nov 2010, Joost van der Sluis wrote:
On Wed, 2010-11-24 at 20:57 +0100, Michael Van Canneyt wrote:
On Wed, 24 Nov 2010, Alexsander Rosa wrote:
But it is
On Tue, 2010-11-30 at 11:54 +0100, michael.vancann...@wisa.be wrote:
On Tue, 30 Nov 2010, Joost van der Sluis wrote:
On Mon, 2010-11-29 at 17:57 +0100, michael.vancann...@wisa.be wrote:
Procedure TSQLConnection.CreateDefaultTransaction;
If coAutoTransaction is set, and TSQLQuery does
I think we should not change a thing, until the problem is clear. Maybe
we can come up with some 'general' transaction-isolation levels. The
reason they are not implemented in a general way is that each DB has
it's own locking-style.
Here is nice explanation of isolation levels, general
Joost van der Sluis wrote:
If I could ask: where can I find a description of how TSQLQuery etc.
should be used for non-trivial applications? For example, if I want to
set up an explicit transaction, insert a few hundred rows of data, and
then make an explicit decision on whether I commit or
On Wed, 2010-11-24 at 17:40 -0200, Alexsander Rosa wrote:
But it is transparent to the libpq programmer; why it's not
transparent with sqldb?
To learn people that they have to use transactions. There are only a
very few cases in which you don't need a transaction.
But most programmers do a:
On Wed, 2010-11-24 at 20:57 +0100, Michael Van Canneyt wrote:
On Wed, 24 Nov 2010, Alexsander Rosa wrote:
But it is transparent to the libpq programmer; why it's not transparent
with sqldb?
Correction: it can be transparant in libpq.
But we can make it so in SQLDB.
The SQLDB
On Mon, 29 Nov 2010, Joost van der Sluis wrote:
On Wed, 2010-11-24 at 20:57 +0100, Michael Van Canneyt wrote:
On Wed, 24 Nov 2010, Alexsander Rosa wrote:
But it is transparent to the libpq programmer; why it's not transparent with
sqldb?
Correction: it can be transparant in libpq.
But
On Fri, 2010-11-26 at 12:14 -0200, Alexsander Rosa wrote:
2010/11/26 Mark Morgan Lloyd markmll.laza...@telemetry.co.uk
I've tried to use sqldb but it adds too much
unneeded overhead. Under PostgreSQL it
actually
On Mon, 2010-11-29 at 17:57 +0100, michael.vancann...@wisa.be wrote:
On Mon, 29 Nov 2010, Joost van der Sluis wrote:
On Wed, 2010-11-24 at 20:57 +0100, Michael Van Canneyt wrote:
On Wed, 24 Nov 2010, Alexsander Rosa wrote:
But it is transparent to the libpq programmer; why it's not
You mean to TEACH people and you assume too much about me.
2010/11/29 Joost van der Sluis jo...@cnoc.nl
On Wed, 2010-11-24 at 17:40 -0200, Alexsander Rosa wrote:
But it is transparent to the libpq programmer; why it's not
transparent with sqldb?
To learn people that they have to use
On Mon, 29 Nov 2010, Joost van der Sluis wrote:
On Mon, 2010-11-29 at 17:57 +0100, michael.vancann...@wisa.be wrote:
On Mon, 29 Nov 2010, Joost van der Sluis wrote:
On Wed, 2010-11-24 at 20:57 +0100, Michael Van Canneyt wrote:
On Wed, 24 Nov 2010, Alexsander Rosa wrote:
But it is
Joost van der Sluis wrote:
On Wed, 2010-11-24 at 17:40 -0200, Alexsander Rosa wrote:
But it is transparent to the libpq programmer; why it's not
transparent with sqldb?
To learn people that they have to use transactions. There are only a
very few cases in which you don't need a transaction.
Joost van der Sluis wrote:
PostgreSQL gets locked, I mean, the tables being used by sqldb can't
be modified (new columns, new constraints, etc) while the sqldb
connection is active, even if it's a read-only SELECT. If someone is
testing a heavy report the tables affected can't be changed by the
On Sun, 28 Nov 2010, Marco van de Voort wrote:
On Wed, Nov 24, 2010 at 08:57:48PM +0100, Michael Van Canneyt wrote:
The SQLDB model is in fact modeled after Firebird.
Firebird offers more control over the transactions.
We did not want to take away this possibility, so we modeled sqldb on
On Fri, 26 Nov 2010, Alexsander Rosa wrote:
Don't get me wrong, I'm all for innovations in Free Pascal/Lazarus. However, in
this particular case, I don't think the
multiple transactions per connection approach, supported only by selected
databases, is the best solution. IMHO it should
be an
On Friday 26 November 2010 15:14, Alexsander Rosa wrote:
With DBExpress or Zeos this problem does no occur. They use the so-called
Zeos ? This is simply NOT true, at least with Zeos 6.6.5.
If you chosen correct tiTransactionIsolation (eg. tiReadCommited) then pgsql
connections automatically
I'm using it from SVN too.
2010/11/26 zeljko zel...@holobit.net
On Friday 26 November 2010 15:14, Alexsander Rosa wrote:
With DBExpress or Zeos this problem does no occur. They use the
so-called
Zeos ? This is simply NOT true, at least with Zeos 6.6.5.
If you chosen correct
Martin Schreiber wrote:
Firebird has the ability for 'named transactions'. It is possible to run
multiple transactions in parallel on a single connection. PostgreSQL does not
offer this possibility. In PQ there is for every transaction a separate
connection and even an additional server
On Thursday, 25. November 2010 09.37:05 Mark Morgan Lloyd wrote:
Martin Schreiber wrote:
Firebird has the ability for 'named transactions'. It is possible to run
multiple transactions in parallel on a single connection. PostgreSQL does
not offer this possibility. In PQ there is for every
On Thu, 25 Nov 2010, Alexsander Rosa wrote:
I've ported my OPF from DBExpress to Zeos IFDEF'ing less than 10 lines. As
DBExpress, Zeos supports a single transaction per connection. My OPF uses a
single connection with 3 TSQLQuery/TZQuery for different purposes. It's very
rare to have the
Well, DBExpress is the de facto standard for Delphi apps since D6.
IMHO sqldb should have used its architecture as inspiration.
2010/11/25 michael.vancann...@wisa.be
On Thu, 25 Nov 2010, Alexsander Rosa wrote:
I've ported my OPF from DBExpress to Zeos IFDEF'ing less than 10 lines. As
On Thu, 25 Nov 2010, Alexsander Rosa wrote:
Well, DBExpress is the de facto standard for Delphi apps since D6.
IMHO sqldb should have used its architecture as inspiration.
It was. Partially.
Because it doesn't offer full transaction support for Firebird, and I
require that, I changed the
Implicit transaction even in C using libpq, even for a mere SELECT? Are you
sure?
2010/11/23 Mark Morgan Lloyd markmll.laza...@telemetry.co.uk
Martin Schreiber wrote:
On Tuesday, 23. November 2010 18.01:35 Alexsander Rosa wrote:
I think the statement without a transaction, Postgres will do
On Wednesday, 24. November 2010 18.52:11 Alexsander Rosa wrote:
Implicit transaction even in C using libpq, even for a mere SELECT? Are you
sure?
Yes:
http://www.postgresql.org/docs/8.3/static/tutorial-transactions.html
PostgreSQL actually treats every SQL statement as being executed within a
But it is transparent to the libpq programmer; why it's not transparent with
sqldb?
2010/11/24 Martin Schreiber mse00...@gmail.com
On Wednesday, 24. November 2010 18.52:11 Alexsander Rosa wrote:
Implicit transaction even in C using libpq, even for a mere SELECT? Are
you
sure?
Yes:
On Wed, 24 Nov 2010, Alexsander Rosa wrote:
But it is transparent to the libpq programmer; why it's not transparent with
sqldb?
Correction: it can be transparant in libpq.
But we can make it so in SQLDB.
The SQLDB model is in fact modeled after Firebird.
Firebird offers more control
Could you point which files should be patched?
2010/11/24 Michael Van Canneyt mich...@freepascal.org
On Wed, 24 Nov 2010, Alexsander Rosa wrote:
But it is transparent to the libpq programmer; why it's not transparent
with sqldb?
Correction: it can be transparant in libpq.
But we can
On Wed, 24 Nov 2010, Alexsander Rosa wrote:
Could you point which files should be patched?
I think it could be done by simply patching sqldb.pp itself.
My suggestion:
1. Add an option 'autotransaction' to TSQLConnection. Best in the form of
TSQLConnectionOption = (coAutoTransaction);
On Wednesday, 24. November 2010 20.40:38 Alexsander Rosa wrote:
But it is transparent to the libpq programmer; why it's not transparent
with sqldb?
It is, with tao_fake set (MSEgui). The different DB's have very different
transaction models. As Michael writes, sqldb is designed to get the full
Before anything else I'd like to say that I'm entirely familiar with
transactions in the SQL context. However I've been having a bit of
difficulty sorting out the relationship between a TPQConnection,
multiple TSQLQuery, and transaction object(s).
I'm roughing out a program which I am trying
This was the main reason I gave up on sqldb and moved to Zeos.
2010/11/23 Mark Morgan Lloyd markmll.laza...@telemetry.co.uk
Before anything else I'd like to say that I'm entirely familiar with
transactions in the SQL context. However I've been having a bit of
difficulty sorting out the
On Tue, 2010-11-23 at 16:01 +, Mark Morgan Lloyd wrote:
Before anything else I'd like to say that I'm entirely familiar with
transactions in the SQL context. However I've been having a bit of
difficulty sorting out the relationship between a TPQConnection,
multiple TSQLQuery, and
Joost van der Sluis wrote:
On Tue, 2010-11-23 at 16:01 +, Mark Morgan Lloyd wrote:
Before anything else I'd like to say that I'm entirely familiar with
transactions in the SQL context. However I've been having a bit of
difficulty sorting out the relationship between a TPQConnection,
I think the statement without a transaction, Postgres will do nothing,
ever. For example: you can write a small C program using libpq that
executes a simple SELECT without any transaction SQL code. Here's a comment
from PostgreSQL's website [1]:
/*
* Our test case here involves using a
On Tuesday, 23. November 2010 18.01:35 Alexsander Rosa wrote:
I think the statement without a transaction, Postgres will do nothing,
ever. For example: you can write a small C program using libpq that
executes a simple SELECT without any transaction SQL code. Here's a comment
[...]
It uses an
Martin Schreiber wrote:
On Tuesday, 23. November 2010 18.01:35 Alexsander Rosa wrote:
I think the statement without a transaction, Postgres will do nothing,
ever. For example: you can write a small C program using libpq that
executes a simple SELECT without any transaction SQL code. Here's a
59 matches
Mail list logo
