Re: need good editor for postgreSQL

--- Mark Deering <reidardeering(at)yahoo(dot)com> wrote:
>
> I have fair programming experience (VBA, Java, Python) but my end-users want GUIs and nothing
> but. No TLAs ("Three Letter Acronyms"). If they can't use it right away, they don't believe in
> it. I need to make any new database look good fast, or else I'm back to downloading their stuff
> to my main every week. I fear no software but my colleagues are demanding, and I have no time.
> I want to get something up and running that they can see and that looks like something they are
> used to. I want to transition before they know anything has happened.. Thus, I work over-time
> on my own time until I solve this problem. Needless to say they don't want to pay for anything.

Well my first suggestion is to reply-all so that everyone on this mailing list that IS smarter
than me can give you better answers. ;)

Personally, I have an access database that I reciently migrated. I had many of the same concerns
as you have. Initially, I had all of the forms, reports, and data in access. To start off with,
I spent some time to document the DDL statements that I would need to recreate the DB schema and
relationships in postgresql.

First, I created all of the schema entities on the postgres server. Second I linked these table to
the access front-end using ODBC. Third, I "appended"/inserted the data from access table to
postgresql Linked tables. Fourth, I dropped the access tables and renamed to postgresql linked
tables to the original table names. The reports and forms didn't seems to care since they
continued to work as expected.

However, there are some points to watch for. If you have alot of queries like:

SELECT * from a_one_and_a_half_gigabite_table;

Postgres will not be able to give you same data <over ethernet> through-put that a client side
access table will give.

Alternatively, if you are querying small sub-sets of data from a huge table, you will notice that
PostgreSQL wins handsdown against MS-access when you are tranferring data over ethernet.

Another great advantage to splitting the GUI front-end from the DB back-end is that while your
users are making due with MS-access as a front end linked to postgresql, you can seperately being
development on a better custom front-end. Perhaps you could use java for example to do this work.
Once you are done, they can try it out what you have developed. If they like it, great. If they
don't, they can continue to use the access front-end that they know and love.

Here are some links that I've never used, but maybe they will be helpful to you:
http://www.postgresql.org/docs/techdocs.3

check out the sub-heading for "Microsoft Access"

Regards,
Richard Broersma Jr.