Re: Moving from SQL Anywhere to PostGres - First Time

> I hear there are several, But I can't understand why someone would want to
> perform non-graphical tasks using a GUI.

Because it is easier.

I've managed to do everything I need - as well as write a full query
editor/report writer for PostGreSQL.

It is being beta tested now, and I plan on releasing it within the next 2 or
3 weeks.

It adds about 8 extensions to the PostGreSQL language - and does many
things.

You'll see why it is nice to use a nice/pleasant GUI interface.

ie:

  /* Check to make sure all email addresses have valid domain names */
  select lastname,firstname,email  from profiles
    domain check on email

OR

  /* return a list, subtotalling adults and child by state */
  select state,lastname,firstname,email,adults,child from profile
    order by state
        subtotal adults,child on state

OR

/* highlight all credits in red */
select company,balance from accounts
   highlight balance where balance < 0 bgcolor=COLOR:RED


-Robert

"Jasen Betts"  wrote in message news:ihmf86$98d$1@reversiblemaps.ath.cx...

On 2011-01-20, Robert Paresi <firstname@lastname.net> wrote:
> Hello,
>
> We have 700 user install base using Sybase SQL Anywhere 9.02
>
> We are looking at migrating these installations over to PostGres

> 1.  Very Very Short Answer Please - why should we?

postgres is the best database in the universe. :)

> 2.  Does anyone have a utility or migration application to read SQL
> Anywhere
> to go to PostGres

sed ?  Any stock utility is likely to make choices that are sub optimal for
your needs.  with 700 changeovers pending I would want complete control over
how each column is handled.

> 3.  Does PostGres handle column descriptions (ie: you can give each column
> a
> 50 character description) and then access it via SQL Result Set (like I
> can
> do in Sybase)

you can put descriptions on columns, I have not hit a length limit.
(probably several megabytes like other text fields).

Getting descriptions in the same same result set as column data is probably
impractical (see length limit for a possible reason why this has not been
implemented). fetching them separately en-masse and caching them or fetching
or individually afterwards should not be greatly difficult, resultsets are
returned with the column and table indicated.

> 4.  Is there any Date/TimeStamp issues and conversions I need to know
> about.
> I use simply a DATE field and a TIME field - but do not use DATE/TIME
> stamp
> fields together.

time goes upto 24:00:00.999999 just incase you come across a day that long.
so unless that's going to cause problems there should be no issues.
the range supported by date is starts in pre-history and continues
for a few million years into the future.

> 5.  What UI/Developer tools (GUI) are available to manage the database as
> well as add/change columns rather than doing it via SQL commands.

I hear there are several, But I can't understand why someone would want to
perform non-graphical tasks using a GUI.

--
⚂⚃ 100% natural

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general