"Mike Nolan" wrote in message
...
ojunk (Ernest W. Schlich) writes:

As long as whichever database program is selected as the office's primary
data
collection and reporting resource is OLE capable, having Access as either
a
temporary or even perhaps permenate front end to accept TLA data from the
web
is not a bad solution in my opinion.

I've not tried Access with PostgreSQL (the database the USCF is using),
but I did try it with Oracle, and was very unimpressed with the results.

I would be most interested in hearing the details please.

The PostgreSQL development community appears to be unimpressed with Access
as a front end, too.

Ditto.

One of the limitations of PostgreSQL is that it has no native front end
environment for end-user tools, though it has several for developers.
Neither does MySQL, which is what MSA was developed in. The open source
community has not spent a lot of time on front end tools for things like
data entry applications, because they're not easy to develop.

So, they dislike Access as a database front-end, but have no alternative?

To go to an environment where there are native front end tools (such as
Oracle or MS SQL Server) or to use 3rd party front end tools would have
involved a rather large up front expenditure in software that the USCF
was unwilling (or unable) to make, plus considerable time getting
proficient in those tools. What we do NOT need is another badly designed
front end, whether that be in Access or anything else.

I very much agree that a poor design will make even the best software tools
look bad.

George

"Paul Rubin" wrote in message
...

I remember seeing a spreadsheet-like interface for MySQL, but it
probably makes more sense to use a web front end.

My experience has been that Web front-ends make sense for Web applications,
but not for in-house applications. In general, Web applications are much
more tedious to write than non-Web applications. Tools like .Net are
closing that gap, but the gap remains.

George

"George John" writes:
I remember seeing a spreadsheet-like interface for MySQL, but it
probably makes more sense to use a web front end.

My experience has been that Web front-ends make sense for Web applications,
but not for in-house applications. In general, Web applications are much
more tedious to write than non-Web applications. Tools like .Net are
closing that gap, but the gap remains.

I'm more comfortable doing web stuff, but maybe one of these is what
you want (search results from typing "mysql gui" into Freshmeat):

http://freshmeat.net/search/?q=mysql...ojects&x=0&y=0

One reason I prefer web apps is there's no new interface for anyone to
learn. Everyone already understands browsers.

"George John" writes:

I've not tried Access with PostgreSQL (the database the USCF is using),
but I did try it with Oracle, and was very unimpressed with the results.

I would be most interested in hearing the details please.

Aside from the fact that Access kept crashing, it also generated bad SQL
and had problems dealing with Oracle's data concurrency methodology,
as a result of which it was corrupting the database.

This was, admittedly, in 1997-98, and I assume Access has improved from
then, though I think some of the problems may have been due to inadequacies
in the ODBC protocol that are still inherent.

The PostgreSQL development community appears to be unimpressed with Access
as a front end, too.

Ditto.

Check out www.postgresql.org, I don't know that I can summarize the
experiences of others adequately. That's not to say that there aren't
people using Access with PostgreSQL, it just doesn't seem to be all that
popular. Both the MySQL and PostgreSQL communities seem to lean towards
web-based solutions using tools like PHP or perl.

Neither Gary Prince nor I have much expertise in Access, and I for one am
not excited about learning it because I don't see it as a career-enhancing
move. Gary has experience with Delphi (which I have a little VERY OLD
experience with), but I'm not sure that's a great choice for a front end
either. I'm more interested in the back end database engine stuff and
in data analysis and reporting issues, though I have been playing around
with a table-driven general purpose web-based query/forms engine in PHP,
which I am inclined to release into the open source community to fill
the hole there.
--
Mike Nolan

(Mike Nolan) writes:
Neither Gary Prince nor I have much expertise in Access, and I for one am
not excited about learning it because I don't see it as a career-enhancing
move. Gary has experience with Delphi (which I have a little VERY OLD
experience with), but I'm not sure that's a great choice for a front end
either. I'm more interested in the back end database engine stuff and
in data analysis and reporting issues, though I have been playing around
with a table-driven general purpose web-based query/forms engine in PHP,
which I am inclined to release into the open source community to fill
the hole there.

I typed "mysql gui" into the freshmeat.net search form and found a
bunch of front ends for MySQL which look sort similar to the front
ends for Access, Filemaker, etc., though I've never programmed any of
those. I'd be interested to know whether you think those MySQL things
look useful. I tend to use web front ends for everything. Presumably
there's similar GUI stuff for PostgreSQL too though.

"Mike Nolan" wrote in message
...

-snip-

Aside from the fact that Access kept crashing, it also generated bad SQL
and had problems dealing with Oracle's data concurrency methodology,
as a result of which it was corrupting the database.

This was, admittedly, in 1997-98, and I assume Access has improved from
then, though I think some of the problems may have been due to
inadequacies
in the ODBC protocol that are still inherent.

I find it amusing that comments are being made in 2003 about a product that
is nearly six years old. Access has had HUGE improvements over this period
of time. So has the OS that it typically runs on (Windows 2000 and XP and
not Windows 95/98). Provided Access is used for tasks that it was designed
for, it can be a highly productive development environment.

The PostgreSQL development community appears to be unimpressed with
Access
as a front end, too.

I would assume they are unimpressed by EVERYTHING that Microsoft sells.

-snip-

George

"George John" writes:

I find it amusing that comments are being made in 2003 about a product that
is nearly six years old. Access has had HUGE improvements over this period
of time. So has the OS that it typically runs on (Windows 2000 and XP and
not Windows 95/98). Provided Access is used for tasks that it was designed
for, it can be a highly productive development environment.

That's true of nearly anything, George. The problem is deciding what
thing were designed for. In Microsoft's case, it often seems that
they're designed to work well with other Microsoft products but not with
anything else. That was true of Access and Oracle the last time I had
reason to look into pairing the two, and the Oracle developers I have
contact with tell me that they still don't play together well. That's
not true of Oracle and other development platforms, even though Oracle
has its own development platform, so I suspect the problem comes from
Redmond rather than from Redwood Shores. (You won't see a big Microsoft
booth at the Oracle Open World convention, for example, and I think it's
more than just a Larry/Bill thing.)

I'm a Microsoft partner, I have gone to their local seminars, they're
usually about how to sell more Microsoft products than about how to solve
user application problems.
--
Mike Nolan

"Douglas L Stewart" wrote in message
. ..

-snip-

I've dealt with ODBC with IBM DB2 at work lately with Microsoft Access,
and
I can tell you it is still a mess.

Isn't ODBC at least two generations behind the current technology? I
haven't used it in many years.

George

What is "the current technology"?

"George John" wrote in message
...

"Douglas L Stewart" wrote in message
. ..

-snip-

I've dealt with ODBC with IBM DB2 at work lately with Microsoft Access,
and
I can tell you it is still a mess.

Isn't ODBC at least two generations behind the current technology? I
haven't used it in many years.

George

"Douglas L Stewart" wrote in message
. ..
What is "the current technology"?

In Microsoft's world it's ADO.NET.

The technology evolution as I understand it was (from oldest to newest):

1) ODBC
2) DAO and RDO
3) OLE DB
4) ADO
5) ADO.NET

The evolution of providers was:
1) ODBC
2) OLE DB
3) .NET data providers

George


"George John" wrote in message
...

"Douglas L Stewart" wrote in message
. ..

-snip-

I've dealt with ODBC with IBM DB2 at work lately with Microsoft
Access,
and
I can tell you it is still a mess.

Isn't ODBC at least two generations behind the current technology? I
haven't used it in many years.

George