On Wednesday 19 April 2006 04:57, Adrian Maier wrote:
> On 4/19/06, Joost van der Sluis <[EMAIL PROTECTED]> wrote:
> > No, pseudo-code, see Michaels mail for the real commands.
>
> Yep, I've seen them. Interesting. It's good to know about them .
>
> > > Indeed, it's not visible. Therefore: the same user can see that record
> > > in one place, and at the same time he doesn't see the record in another
> > > place. Is this truly a good thing ?
> >
> > No. I would use one transaction for one user.
>
> This happens in a middle-tier application, i guess.
>
> > Or you can decide to use one transaction for each form, or one for each
> > thread. That's all up to the developer.
>
> I see.
>
> Just a last note (maybe this is useful for someone):
> When using postgresql and there are too many users, it is possible to use
> connection polling : http://pgpool.projects.postgresql.org/
>
>
> Adrian Maier
>
Since I believe I'm the guy that started this thread I think I'll take the
time to explain in more detail how and why I started the thread.
In the app I want to develop I would like the user to be able to have open
several forms at once. As an example I could open the customer form several
times and each form would be independent of each other. Each customer form
could do lookups, change data etc. You see examples of what I'm describing
in accounting programs. I started out attempting to use a data module. The
data module solution sort of worked (although I would crash for unknown
reasons) but required that the transaction control be opened and closed often
as I moved from form to form and from action to action (selects, updates,
deletes, inserts). Controlling a single transaction control from each form
was a pain. So why not have a number of transactions available – one for
each form. That's when I discovered that one connection would not allow
multiple transaction. You see I was leaving the transaction active. When I
opened a second form and attempted to select any data I'd get the error
stating that I had an open transaction. This started me thinking why does
this limitation exist? So I started asking questions. Shouldn't each
transaction have it's own session. Why is it that when I do a read (select)
I must have a transaction open (a begin is sent to the database engine). In
the end I have been told that it is a limitation of Postgres not SQLdb. So
in the end I choose to use a new connection for each form. I guess the real
reason I questioned all of this was because I did not have any such
limitation when using Foxpro to connect to Postgres. I could make all the
reads I wanted without having to start a transaction. But I was forced to
control updates, inserts, and deletes within transactions.
Yes I understand that I could write a Unit that contains a routine to handle
my reads:
procedure GetSqlData(parameter myquery);
Open the transaction;
Make the select;
Close the transaction;
And the above started more questions. When I started experimenting with the
call I noticed that my code size got larger. I would have thought just the
reverse would have occurred. I became concerned when I realized that I was
passing objects as parameters. So then I asked the question about how the
compiler handled the call. Which is why this thread is labeled “FPC
question”. I was concerned that I had missed a compiler switch or was doing
it wrong. In the end I have no answer. The size of the bin is not that
large (I have about 8 forms and code = approx. 15.1 megs) and it seems to run
fast with calling a central routine or just having a connection for each
form. Programming is a lot easier when I just add a connection for each
form. But then I open lots of connections. Postgres can handle thousands of
connections with little overhead. So why worry – be happy to coin a song.
John
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
