PostgreSQL and QT4 automate id problem!

[nnidza]

Ok, it works now.
Wysota thank you for your advice, I'll keep that on my mind when I make some more complex forms...
I didn't understand your solution Jacek. What is serial exactly? A new data type? Sorry I am not so familiar with PostgreSQL.
GreyGeek you solution works! I don't need any transactions now as I am under the PostgreSQL protections? Am I right?

And some of you mentioned trigers. No clue so far... Is it a complex explanation to drop a few lines before I read a tutorial?

Marry Christmas to all of you that celebrates...

[wysota]

And some of you mentioned trigers. No clue so far... Is it a complex explanation to drop a few lines before I read a tutorial?

http://en.wikipedia.org/wiki/Database_trigger

Marry Christmas to all of you that celebrates...

Thanks

[jacek]

I didn't understand your solution Jacek. What is serial exactly? A new data type?

Yes, it's a special data type. It's an equivalent of GreyGeek's solution, only shorter.

http://www.postgresql.org/docs/8.2/s...ATATYPE-SERIAL

[GreyGeek]

Yes, it's a special data type. It's an equivalent of GreyGeek's solution, only shorter.

http://www.postgresql.org/docs/8.2/s...ATATYPE-SERIAL

Last week I upgraded from PostgreSQL 8.1.4 to 8.2 on my W2K workstation. My compiles stopped with an error while attempting to load a dll.

qsqlpsql.dll loaded ssleay32.dll which loaded leay32.dll which failed because the first dll was looking for functions which weren't present on one of the secure shell dlls. Dependencychecker showed the problem, but I am at home and don't have access to my notes. But, basically, when Qt attempts to load a library and it fails, it is marked so that it won't load again until the library is recompiled, or at least touched, so that the timestamp changes. Then Qt will attempt to load it again.

When I reverted back to 8.1.4 Qt4.2.2 apps compiled OK.

[GreyGeek]

I don't need any transactions now as I am under the PostgreSQL protections? Am I right?

No. You still may need to use transactions.

A classic example is the General Journal posting. Say you have a table containing daily postings of debits and credits to various accounts. You want to post those amounts to their specific debit and credit accounts to that your accounts remain balanced. If any of them fail you want to revert all of them. You do that by
Begin;
post the daily transactions to the general ledger
Commit;
(or Rollback if things didn't go well).
See http://www.postgresql.org/docs/8.1/i...nsactions.html

This avoids the "dirty read" problem:
http://www.informit.com/articles/art...&seqNum=6&rl=1

[GreyGeek]

Triggers are very useful. Their use is only limited by your imagination.

A simple use is backing up changes made by clerks. A trigger on the UPDATE would save the *.NEW or *.OLD record in a history table automatically. Then, if a question arises as to who changed what and when you can consult the history table. If you need to revert a change you can use the history table as the source of the previous record.