SQL Power Software Forum

Great news about auto-increment types

Now the only think needed to be usable for my project is PGSQL boolean fields

) maybe in the next one

I've just committed the ability to specify BOOLEAN as a column type.

It makes a real BOOLEAN column in PostgreSQL, and uses the alias called "BOOLEAN" in MySQL (which is really just a TINYINT), and makes a TINYINT in the commercial databases (DB2, Oracle, MS SQL Server) which of course don't have a BOOLEAN type at all.

This will be available in the upcoming nightly build, dated 2007-11-07.

Important caveat: Earlier today, we committed a large change to how project files are saved and loaded. The file format and behaviour were not changed in any way, and the new arrangement passes our test suite with flying colours. But only time will tell if that change introduced an obscure bug our tests haven't uncovered.

I don't want to discourage you from using the nightly build with the BOOLEANs, but please do report any problems if you run into them.

Wow, thanks!

I´ll try it as soon as I get on work tomorrow.

Jonathan, none of the downloads for the nightly builds are working. I´m trying at http://nightlybuild.sqlpower.ca/ is this right ? Where can I get them ?

Nelson
Blog: www.aocontrario.com

Hello Jonathan,

After the nightly build problem been fixed, I tried the nightly build of 7/11 and 8/11 . And in both I got the same error:

"The architect keeps it´s list of connections in a file called PL.INI. Your PL.INI location is not set.

You can browse bla bla..."

Then I got an option of Browse or Create,.if I browse I can´t find it. If I create it, I got a null error.
Tried to install over the existing installation and to uninstall before install. None of them worked.
There is some special procedure for using nightly builds ?

Nelson
Blog: www.aocontrario.com

Hi Nelson,

Sorry about all this trouble!

We were able to resolve this problem, which was actually introduced a few days ago. The upcoming nightly build (2007-11-09) should work properly.

Enjoy!

This message was edited 1 time. Last update was at 2007-11-08 19:22:52

NP. it´s a free solution after all. I´m not complaining, I should be helping you guys

Jonathan, just want to thank you. It worked on the last build 11/09. I could sucessfully reverse engineer my database and recreate it using auto-increment fields and boolean types.

When I reverse engineer it the serial fields didn´t had the check in the "auto-increment" option, the fk fields type didn´t match the id field type, and the boolean field still where bits (but now we have the boolean type). As soon as I did these modification in the model, all worked up.

Great job!

Thank you and your team

Thanks for the feedback, Nelson!

We definitely need to fine-tune the auto-increment support some more, both with reverse engineering and the "compare dm" feature.

About the boolean reverse engineering problem, the PostgreSQL driver makes no distinction between BIT and BOOLEAN. Apparently the PosrgreSQL JDBC driver developers consider this a feature, since the JDBC specification says BIT and BOOLEAN are functionally equivalent.

But driver quirks have never stopped us in the past.

You'll find reverse engineering for BIT and BOOLEAN types will work as expected starting with the upcoming nightly build, dated 2007-11-10.

The reverse engineering of serial columns is a bit more complicated.. There is no flag in the metadata provided by JDBC to indicate if a certain column auto-increments. On a platform-by-platform basis, we could determine the auto-increment status of a column (for instance, on PostgreSQL, the column's default value will start with "nextval('").

About the FK field type problems, can you provide more detail?

-Jonathan

Yes Jonathan, about the FK, I tried to recreate the problem in order to describe it, but it didn´t happened anymore. Maybe it has been fixed in the latest nightly build. It was a difference between the PK type and the correspondent FK type, that generated a warning from the database saying something like: "this relationship will generate costly selects" or something like that. If I came across with it in the near future, I let you know.

thnx again,
Nelson Teixeira
Blog:www.aocontrario.com

Ok, we will keep an eye out for that message from PostgreSQL too!