Operationsengineer,

Thanks for the feedback.

To be honest, I'm not at all excited about having to use a web
browser as a means of data entry. Compared to an access frontend,
they are clunky and slow. I suppose that they might be able to
achieve some security through password and IP restriction? Again, I
am a novice so help me out here. But a browser interface would be
an absolute last resort. Rather than use a browser, it would be
preferable to do something similar to the procedure outlined here
with PG + Access97:

http://sevasoftware.com/access/index...asonforporting

I'm curious to hear from someone who had similar priorities, tried
a few different things, found something that worked well, and can
explain how to map from a typical access process to a postgres +
whatever process.

For example, when I hear that people can do all the backend table
creation stuff via the command line, I'd love to know how they can
see everything they have created and test that it works, as you can
easily do in Access. As I said, a mapping from Access to PG +
whatever. Surely it shouldn't be too hard for someone who made the
transition from Access to PG to give a brief explanation of what
the 8 steps in my database creation process are in their PG
environment. Even someone who just has a good grounding in PG and
making solid internal business database applications should be able
to do it.

It's not as if my needs are unique. Someone upgrading from access
needs the scalability, robustness, ability to handle complexity and
ease of interfacing that postgres provides. Databases used
internally by businesses tend to have a few users performing _lots_
of data entry/transactions/reporting, rather than lots of users
performing small chunks of work. There has to be some sort of open source front end solution that is tailored to this type of work, where a mouse is touched only when absolutely necessary.

And I don't mind waiting a week or more before I make an
interface/language decision. IME it's rarely a good idea to dive in
at the deep end without getting a good sampling of opinions from
those who have already gone before. What's an extra week (or
month!) if 6 months (or 6 years) down the track you suddenly
realize that you have made the wrong decision and need to rework
everything? For example, I took a good 3 weeks or more to decide on
postgres. If you had asked me early last week which backend I was
going to use, I would have told you MySQL.

> make the interface decisions and then decide on a
> language that can get it done and *get started*. stay
> in touch here and with the forums, newsgroups, mailing
> lists, etc. for the language / framework that you
> choose.
>
> good luck.


--
__________________________________________________ _
Play 100s of games for FREE! http://games.mail.com/


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

hi roger...
Sorry havent followed this converstation from the start and Im afraid I
dont fit into the' have tried this and it works well' category, but it
DOES rate highly on my list of things to do:
www.dabodev.com and might be worth you while to look - more for
generating the user interface than the schema though.


On Wed, 2006-08-16 at 01:26 -0500, Roger Rasmussen wrote:
> Operationsengineer,
>
> Thanks for the feedback.
>
> To be honest, I'm not at all excited about having to use a web
> browser as a means of data entry. Compared to an access frontend,
> they are clunky and slow. I suppose that they might be able to
> achieve some security through password and IP restriction? Again, I
> am a novice so help me out here. But a browser interface would be
> an absolute last resort. Rather than use a browser, it would be
> preferable to do something similar to the procedure outlined here
> with PG + Access97:
>
> http://sevasoftware.com/access/index...asonforporting
>
> I'm curious to hear from someone who had similar priorities, tried
> a few different things, found something that worked well, and can
> explain how to map from a typical access process to a postgres +
> whatever process.
>
> For example, when I hear that people can do all the backend table
> creation stuff via the command line, I'd love to know how they can
> see everything they have created and test that it works, as you can
> easily do in Access. As I said, a mapping from Access to PG +
> whatever. Surely it shouldn't be too hard for someone who made the
> transition from Access to PG to give a brief explanation of what
> the 8 steps in my database creation process are in their PG
> environment. Even someone who just has a good grounding in PG and
> making solid internal business database applications should be able
> to do it.
>
> It's not as if my needs are unique. Someone upgrading from access
> needs the scalability, robustness, ability to handle complexity and
> ease of interfacing that postgres provides. Databases used
> internally by businesses tend to have a few users performing _lots_
> of data entry/transactions/reporting, rather than lots of users
> performing small chunks of work. There has to be some sort of open source front end solution that is tailored to this type of work, where a mouse is touched only when absolutely necessary.
>
> And I don't mind waiting a week or more before I make an
> interface/language decision. IME it's rarely a good idea to dive in
> at the deep end without getting a good sampling of opinions from
> those who have already gone before. What's an extra week (or
> month!) if 6 months (or 6 years) down the track you suddenly
> realize that you have made the wrong decision and need to rework
> everything? For example, I took a good 3 weeks or more to decide on
> postgres. If you had asked me early last week which backend I was
> going to use, I would have told you MySQL.
>
> > make the interface decisions and then decide on a
> > language that can get it done and *get started*. stay
> > in touch here and with the forums, newsgroups, mailing
> > lists, etc. for the language / framework that you
> > choose.
> >
> > good luck.
>
>

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend