Re: Recomended front ends?

From: Rich Shepard <rshepard(at)appl-ecosys(dot)com>
To: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Recomended front ends?
Date: 2019-08-08 19:10:27
Message-ID: alpine.LNX.2.20.1908081202430.9087@salmo.appl-ecosys.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 8 Aug 2019, Tim Clarke wrote:

> We tried Django without any pleasant results.

Tim,

That's unexpected and too bad.

> I'd also caution using MS Access, we're desperate to get away from it.
> Sharing code has challenges and it is horribly aggressive with caching
> unless you use un-bound forms and write all the CRUD interface code
> yourself.

Slightly off-topic, but I've not seen anything good about Access. My
understanding is it's a flat-file database intended as a user front end to
Microsoft's relational database product. My experiences with those who use
it have been painful.

Just yesterday I downloaded a very large database of fisheries data from a
federal agency and have started translating it to postgres using the
mdbtools. There's no schema provided, only 32 pages of table columns and
types without descriptions of the column names. No primary keys, no foreign
keys, and only 66 tables were found in the .mdb file while all table names
starting with s through z were not available. There are also many tables
that hold redundant data which should not exist as the contents are easily
generated by SQL queries. It will take me a while to make it a working
relational database.

Rich

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Basques, Bob (CI-StPaul) 2019-08-08 19:26:22 Re: Recomended front ends?
Previous Message Bryn Llewellyn 2019-08-08 18:35:23 Re: Why must AUTOCOMMIT be ON to do txn control in plpgsql procedure?