Future of access?

[John]

Hi

What future does access have after the release of vs 2005/sql 2005? MS
doesn't seem to have done anything major with access lately and presumably
hoping that everyone migrates to vs/sql.

Any comments?

Thanks

Regards

[Tom van Stiphout]

On Sat, 28 May 2005 19:18:20 +0100, "John" <Jo**@nospam.infovis.co.uk>
wrote:

Review this; then let's talk again.
http://msaccessadvisor.com/doc/14978

-Tom.

Hi

What future does access have after the release of vs 2005/sql 2005? MS
doesn't seem to have done anything major with access lately and presumably
hoping that everyone migrates to vs/sql.

Any comments?

Thanks

Regards

[Ken Snell [MVP]]

See these links to provide some info:

[quote from Access Advisor] Microsoft Access lead program manager Clint
Covington says, "You'll find a strategic commitment to radically upgrade the
quality of Access applications by improving the core forms and reports
experience, using Jet as the query processor." [/quote]

http://msaccessadvisor.com/doc/14978
http://msaccessadvisor.com/doc/16480

--

Ken Snell
<MS ACCESS MVP>

"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:eb**************@TK2MSFTNGP14.phx.gbl...

Hi

What future does access have after the release of vs 2005/sql 2005? MS
doesn't seem to have done anything major with access lately and presumably
hoping that everyone migrates to vs/sql.

Any comments?

Thanks

Regards

[Albert D.Kallal]

"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:eb**************@TK2MSFTNGP14.phx.gbl...

What future does access have after the release of vs 2005/sql 2005? MS
doesn't seem to have done anything major with access lately and presumably
hoping that everyone migrates to vs/sql.

Any comments?

First, ms-access makes a great front end to sql server. So, you kind of have
to consider ms-access a developers tool like c++, or VB, or vb.net.

Remember, with sql server, or oracle, you can't create a form, or even a
user interface. So, if you move to sql server, what will you make the forms
with?

ms-access is primarily a developer tool that lets you build a interface. You
can build this interface, and connect to the JET engine, or connect to sql
server. Thus, you really can't outgrow ms-access in terms of users. It
would be wrong to think as ms-access as a database (it is not). Ms-access is
a tool that lets you build applications, and lets you CONNECT to a database
engine of your choice. So, if you got a oracle database, ms-access is still
a great tool to use, and connect to that database.

As for new features? Well, each version of ms-access tends to bring us along
for the Microsoft ride for technology. When class objects became all rage in
programming circles, we got that feature added to access 97.

You can read about class objects and why you would use them here:
http://www.members.shaw.ca/AlbertKal.../WhyClass.html

When Microsoft came out with ADO (active data objects), then for access
2000, we got ado added to ms-access. When ms-access 2002 came along, XML was
all the rage, and we got even better support for XML in access 2003. And,
access 2003 also let you use share point services.

Further, while you can't write web services in ms-access, you can certainly
CONSUME web services. The reason why you can do this is that Microsoft
released the soap add in tool kit for ms-access. So, if you want to use .net
services via SOAP, or use things like XML...you now can. Hence, you can
consume .net web services with ms-access. So, from a developers point of
view, ms-access gets most of the new technologies that Microsoft comes out
with. They have consistently for the last 10 years added new technologies
to ms-access that they are using for building software.

If you look at the above additions to ms-access, you can clearly see that as
Microsoft comes out with new technologies, they have been adding them to
ms-access. And, if you think about the above features, MOST are not actual
database features, but simply additions to what developers would expect with
a developers tool.

So, I never really thought of ms-access as a database, and the fact that you
can (and should) choose the appropriate database engine for your task at
hand never really changed the fact that you can use ms-access with your
database of choice.

If you want to pick oracle as your database, you can. However, you
can't build a form with a oracle database..and you can with ms-access.

So, you most certainly
can use ms-access to build the application, and use oracle as the database
for this ms-access application. ms-access is thus a tool to 'access' a
database, but ms-access is not really a database.

As for other new features in a2003 that I like and use? Well, you can change
the font size in the sql view (I really like that feature). Another feature
is ms-access now supports themed controls. This makes your "old" software
kind of look new. Here is some screen shots of old vs new. (the only thing
done was turn on themes).

http://www.members.shaw.ca/AlbertKal...heme/index.htm

There is some more screen shots here:

http://www.members.shaw.ca/AlbertKal...erFriendly.htm

Another feature is automatic
error checking for common errors in forms and reports.
Error checking points out errors, such as two controls
using the same keyboard shortcut, and the width of a report
being greater than the page it will be printed on.
Enabling error checking helps you identify errors and
correct them.

The Smart tag help appears in reprot desing also is nice.

And, when you change a field property in the table design, you can have
that change prorogate thought out the application (forms and reports will be
updated to reflect this change).

There is a bunch of other features I don't care...nor use in a2003. However
Microsoft continues to work on the next great version, and if the above
history is any indication of the path of the product, then we will continue
to see new features..and new that MS comes out with integrated into that
developers product.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[David W. Fenton]

"John" <Jo**@nospam.infovis.co.uk> wrote in
news:eb**************@TK2MSFTNGP14.phx.gbl:

What future does access have after the release of vs 2005/sql
2005? MS doesn't seem to have done anything major with access
lately and presumably hoping that everyone migrates to vs/sql.

Have you tried checking Google Groups for this newsgroup to see if
this topic has been discussed before?

Free clue: massive discussion of the topic within the last month.

Free hint: you look not very bright when you ask obvious questions
like this without having checked the archives.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Albert D.Kallal]

>..and new that MS comes out with integrated into that
developers product.

Should read:

and that as MS comes out with new things, they are integrated into
ms-access.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[Sylvain Lafontaine]

The future of Access for whom?

If you are talking about secretaries and the like, then quite probably the
next version of Access will be much more better; expecially when it comes to
its integration with Office and Sharepoint. For exemple, I won't be
surprised if there are a better way of doing a mail merge between Word and
Access or to integrate data from Access into a word document. The actual
interface between Access and Word is very ineffective and there a lot of
ameliorations to make there.

Probably that there will be also a lot of other small ameliorations, like
maybe an easy way of printing multiple reports into a single document, the
possibility of writing comments inside queries, to add fields not from the
recordset to a continuous forms and other things like that.

However, for the developers of enterprise solutions; Access seems now to
have become a dead-end.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF
"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:eb**************@TK2MSFTNGP14.phx.gbl...

Hi

What future does access have after the release of vs 2005/sql 2005? MS
doesn't seem to have done anything major with access lately and presumably
hoping that everyone migrates to vs/sql.

Any comments?

Thanks

Regards

[Tony Toews]

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote:

However, for the developers of enterprise solutions; Access seems now to
have become a dead-end.

In what sense?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Albert D.Kallal]

> However, for the developers of enterprise solutions; Access seems now to

have become a dead-end.

Well, I don't think ms-access every was a enterprise solution anyway.
However, do remember that 99% of business in the USA is a small business.
So, while you can get all wound up about big business, they don't represent
any sizeable factor here. So, while enterprise solutions represents 1% of
the business market, ms-access will happily cover the 99% part. Point in
fact, this means the enterprise market never was large, and never was part
of ms-access anyway.

However, for most business, in fact 99% of business out there ms-access is a
ideal tool for software development. And, in fact 99% of business will NOT
outgrow ms-access. Even if you got 50-75 users, ms-access + sql server is a
great solution, and will not even break out in a sweat with such low numbers
of users.

However, for sure, for the larger enterprise development (that represents 1%
of business in the market), those larger business were never using ms-access
for enterprise solutions anyway. I don't think those enterprise solution
providers should be holding their breath for the next version of ms-access
to come out and grab that 1% that ms-access never represented in the first
place.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[Sylvain Lafontaine]

Excerpt for the SQL part, the development of fancy stuff in Access are
mainly based on three things: VBA, Recordsets and ActiveX (COM/DCOM).

Essentially, Microsoft has stopped support for VB6, ASP and DTS; which means
that outside of Access and Office, that are no longer any
support/development/use for languages closely related to VBA, ie: VB and
VBScript. (Of course, I have put apart VB.NET for obvious reasons.)

This also means that outside of Access/Office, support, development and use
of the Recordsets technology is also practically stopped.

Finally, the end of VB6 also means that they is no any longer any way for
the easy creation of COM components. Of course, if you don't need them,
then this won't bother you; however, for those situations where you don't
have the choice - for exemple when you have to interface with an existing
library with no available ActiveX components - then you are now stuck to go
the C++/ATL way; which is far from being an easy way for a newbie.

Seriously, would you suggest to a newcomer, someone who doesn't know VBA,
ADO, ATL and the .NET Framework and who doesn't have to support a legacy
application, to start learning these things instead of VB.NET, C# and
ADO.NET ?

It appears that VBA, Recordsets and COM are now on an isolated island and
that this island will become more and more isolated in a fast way.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF
"Tony Toews" <tt****@telusplanet.net> wrote in message
news:ro********************************@4ax.com...

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote:

However, for the developers of enterprise solutions; Access seems now to
have become a dead-end.

In what sense?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Vadim Rapp]

SL> Seriously, would you suggest to a newcomer, someone who doesn't know
SL> VBA, ADO, ATL and the .NET Framework and who doesn't have to support a
SL> legacy application, to start learning these things instead of VB.NET,
SL> C# and ADO.NET ?

Depends on his purpose. If it is productive creating workhorse applications
with great performance, then yes. If being in sync with glossy magazines,
plus impressing job interviewers who know things from those magazines, then
no.

Vadim Rapp

[(PeteCresswell)]

Per "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>:

Seriously, would you suggest to a newcomer, someone who doesn't know VBA,
ADO, ATL and the .NET Framework and who doesn't have to support a legacy
application, to start learning these things instead of VB.NET, C# and
ADO.NET ?

Absolutely not. I don't need or want any more competition in my (to me, at
least) lucrative niche of providing low-cost, quickly-delivered solutions for
clients who need same. -)

VB.NET *really* eats up the manhours.
--
PeteCresswell

[David W. Fenton]

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in news:ef**************@TK2MSFTNGP14.phx.gbl:

Excerpt for the SQL part, the development of fancy stuff in Access
are mainly based on three things: VBA, Recordsets and ActiveX
(COM/DCOM).

What the *hell* do you mean by "recordsets"? EVERY database
application will be operating on recordsets of one form or another.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Sylvain Lafontaine]

By "recordsets", I'm referring to the DAO and ADO implementations of
recordsets in comparaison with the datasets of the .NET framework. In
ADO.NET, the recordsets are so different from their DAO and ADO counterparts
that MS has changed their name to Dataset.

My statement about "recordsets" may look strange at first but if you take a
look at ADO.NET, the answer will become obvious. This is why I didn't give
any further explanation in my other post.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.74...

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in news:ef**************@TK2MSFTNGP14.phx.gbl:

Excerpt for the SQL part, the development of fancy stuff in Access
are mainly based on three things: VBA, Recordsets and ActiveX
(COM/DCOM).

What the *hell* do you mean by "recordsets"? EVERY database
application will be operating on recordsets of one form or another.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in news:uw**************@TK2MSFTNGP15.phx.gbl:

By "recordsets", I'm referring to the DAO and ADO implementations
of recordsets in comparaison with the datasets of the .NET
framework. In ADO.NET, the recordsets are so different from their
DAO and ADO counterparts that MS has changed their name to
Dataset.

My statement about "recordsets" may look strange at first but if
you take a look at ADO.NET, the answer will become obvious. This
is why I didn't give any further explanation in my other post.

You sound a lot like a garden-variety moron who selects the most
recent Microsoft technology just because Microsoft says it's coming
next. Those who did that with ADO after the release of Access 2000
got badly burned, so I think it highly unlikely that any experienced
Access developer would be anxious to start on whatever Microsoft
says is the latest and greatest, and that includes all the .NET
lunacy, which really isn't designed for the same problem space in
which Access excels.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Sylvain Lafontaine]

Just in case you didn't know, you're not obligated to take part in this
discussion.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86...

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in news:uw**************@TK2MSFTNGP15.phx.gbl:

By "recordsets", I'm referring to the DAO and ADO implementations
of recordsets in comparaison with the datasets of the .NET
framework. In ADO.NET, the recordsets are so different from their
DAO and ADO counterparts that MS has changed their name to
Dataset.

My statement about "recordsets" may look strange at first but if
you take a look at ADO.NET, the answer will become obvious. This
is why I didn't give any further explanation in my other post.

You sound a lot like a garden-variety moron who selects the most
recent Microsoft technology just because Microsoft says it's coming
next. Those who did that with ADO after the release of Access 2000
got badly burned, so I think it highly unlikely that any experienced
Access developer would be anxious to start on whatever Microsoft
says is the latest and greatest, and that includes all the .NET
lunacy, which really isn't designed for the same problem space in
which Access excels.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Anne Nolan]

Well just to add my 2 cents, having been programming in C#.Net for the last
8 months or so..

The "dataset" in .Net is not equivalent to a recordset at all. A dataset
can, however, contain several datatables, each of which is more like the
disconnected recordset idea. You fill a datatable with data from a query or
stored procedure. After optionally manipulating the data in a datatable, it
can be used to update the data in the database.

Anne
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:uw**************@TK2MSFTNGP15.phx.gbl...

By "recordsets", I'm referring to the DAO and ADO implementations of
recordsets in comparaison with the datasets of the .NET framework. In
ADO.NET, the recordsets are so different from their DAO and ADO
counterparts that MS has changed their name to Dataset.

My statement about "recordsets" may look strange at first but if you take
a look at ADO.NET, the answer will become obvious. This is why I didn't
give any further explanation in my other post.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.74...

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in news:ef**************@TK2MSFTNGP14.phx.gbl:

Excerpt for the SQL part, the development of fancy stuff in Access
are mainly based on three things: VBA, Recordsets and ActiveX
(COM/DCOM).

What the *hell* do you mean by "recordsets"? EVERY database
application will be operating on recordsets of one form or another.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[lylefair]

David W. Fenton wrote:
"You sound a lot like a garden-variety moron who selects the most
recent Microsoft technology just because Microsoft says it's coming
next. Those who did that with ADO after the release of Access 2000
got badly burned...."
--
I started to use ADO in 1998. I have not been burned with ADO. I do not
know of anyone who has been burned with ADO. I invite all ADO burnees
to state the nature of their burns and the specific ADO causes of them
here in CDMA.

Learning a new technology can be frustrating and time consuming. These,
together with a notion that I may wish to leave Microsoft programs,
have deterred me from advancing very far into the .NET technolgies. But
I expect that should I do so, I will find many strengths and
advantages.

I think it is fair to beginners who use this group to avoid denigrating
technologies which I have not used extensively.

[Steven Zuch]

There is a future for Access, VBA, DAO, ADO *and* .Net products. Technology
is so prevalent in so many types of organizations, with so many different
needs, that there is room and a need for the full range of technologies, old
and new.

I question the experience of anyone who thinks that the most popular desktop
database in the world is going die out in the near future, or that VBA is
dead.

I question the experience of anyone that does not realize the potential in
learning and implementing the latest Microsoft's latest technologies, such
as .Net.

I know of some very high-end sophisticated work being built on Access, but
also of some very sophisticated clients who require the use of .Net for
product development.

And then there is Visual FoxPro which still has a good, dedicated developers
base. This is old technology that was suppose to die out years ago. The
most resent version (VFP 9) was just released, and includes new reporting
technology that is not even included in any of Microsoft's other product
lines. Go figure.

Steven R. Zuch
Cogent Management Inc.

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86...

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in news:uw**************@TK2MSFTNGP15.phx.gbl:

By "recordsets", I'm referring to the DAO and ADO implementations
of recordsets in comparaison with the datasets of the .NET
framework. In ADO.NET, the recordsets are so different from their
DAO and ADO counterparts that MS has changed their name to
Dataset.

My statement about "recordsets" may look strange at first but if
you take a look at ADO.NET, the answer will become obvious. This
is why I didn't give any further explanation in my other post.

You sound a lot like a garden-variety moron who selects the most
recent Microsoft technology just because Microsoft says it's coming
next. Those who did that with ADO after the release of Access 2000
got badly burned, so I think it highly unlikely that any experienced
Access developer would be anxious to start on whatever Microsoft
says is the latest and greatest, and that includes all the .NET
lunacy, which really isn't designed for the same problem space in
which Access excels.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Zlatko Matiæ]

Hello.
I think that there are some latent potentials of Access to be great
universal front-end RAD. I supposse it is possible to achieve great progress
even with old technologies such as DAO and ODBC, if some small modifications
are added such as passing parameters to saved pass-through queries.
"Steven Zuch" <st***@nospam.net> je napisao u poruci interesnoj
grupi:6E****************@fe11.lga...

There is a future for Access, VBA, DAO, ADO *and* .Net products.
Technology is so prevalent in so many types of organizations, with so many
different needs, that there is room and a need for the full range of
technologies, old and new.

I question the experience of anyone who thinks that the most popular
desktop database in the world is going die out in the near future, or that
VBA is dead.

I question the experience of anyone that does not realize the potential in
learning and implementing the latest Microsoft's latest technologies, such
as .Net.

I know of some very high-end sophisticated work being built on Access, but
also of some very sophisticated clients who require the use of .Net for
product development.

And then there is Visual FoxPro which still has a good, dedicated
developers base. This is old technology that was suppose to die out years
ago. The most resent version (VFP 9) was just released, and includes new
reporting technology that is not even included in any of Microsoft's other
product lines. Go figure.

Steven R. Zuch
Cogent Management Inc.

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86...

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in news:uw**************@TK2MSFTNGP15.phx.gbl:

By "recordsets", I'm referring to the DAO and ADO implementations
of recordsets in comparaison with the datasets of the .NET
framework. In ADO.NET, the recordsets are so different from their
DAO and ADO counterparts that MS has changed their name to
Dataset.

My statement about "recordsets" may look strange at first but if
you take a look at ADO.NET, the answer will become obvious. This
is why I didn't give any further explanation in my other post.

You sound a lot like a garden-variety moron who selects the most
recent Microsoft technology just because Microsoft says it's coming
next. Those who did that with ADO after the release of Access 2000
got badly burned, so I think it highly unlikely that any experienced
Access developer would be anxious to start on whatever Microsoft
says is the latest and greatest, and that includes all the .NET
lunacy, which really isn't designed for the same problem space in
which Access excels.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[(PeteCresswell)]

Per Zlatko Matiæ:

I supposse it is possible to achieve great progress
even with old technologies such as DAO and ODBC, if some small modifications
are added such as passing parameters to saved pass-through queries.

But why bother when it can already be done via ADO?
--
PeteCresswell

[cranbrook]

I've read a lot on this subject, a subject that I'm kind of bummed
about, but can't figure out if I missed the one you're
mentioning...care to state the starting date and title of the
discussion? Was it in this newsgroup? Just looked via google and didn't
find anything that fit the bill, or at least what I expected (the
massive part).

David W. Fenton wrote:

"John" <Jo**@nospam.infovis.co.uk> wrote in
news:eb**************@TK2MSFTNGP14.phx.gbl:

What future does access have after the release of vs 2005/sql
2005? MS doesn't seem to have done anything major with access
lately and presumably hoping that everyone migrates to vs/sql.

Have you tried checking Google Groups for this newsgroup to see if
this topic has been discussed before?

Free clue: massive discussion of the topic within the last month.

Free hint: you look not very bright when you ask obvious questions
like this without having checked the archives.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Zlatko Matic]

try this one:

SELECT "ORG_JEDINICE_Copy"."ORGANIZACIJSKA_JEDINICA",
"VRSTE_PROIZVODNJE_Copy"."VRSTA_PROIZVODNJE",
"ORG_JEDINICE_Copy"."KORISNIK",
"KB_MIKROBIOLOGIJA"."TIP_UZORKA", "KB_MIKROBIOLOGIJA"."KONTROLNI_BROJ",
"KB_MIKROBIOLOGIJA"."DATUM_ISPITIVANJA", "KB_MIKROBIOLOGIJA"."STATUS",
"REZULTATI_MIKROBIOLOGIJA"."OZNAKA_UZORKA",
"REZULTATI_MIKROBIOLOGIJA"."OPIS_UZORKA",
"REZULTATI_MIKROBIOLOGIJA"."BROJ_PROSTORIJE",
"REZULTATI_MIKROBIOLOGIJA"."OPIS_PROSTORIJE",
"REZULTATI_MIKROBIOLOGIJA"."KLASA_CISTOCE",
"REZULTATI_MIKROBIOLOGIJA"."GRANUPOZ",
"REZULTATI_MIKROBIOLOGIJA"."GRANAKC",
"REZULTATI_MIKROBIOLOGIJA"."UCESTALOST_BROJ",
"REZULTATI_MIKROBIOLOGIJA"."UCESTALOST_JEDINIC A",
"REZULTATI_MIKROBIOLOGIJA"."REZULTAT",
"REZULTATI_MIKROBIOLOGIJA"."MJERNA_JEDINICA",
"REZULTATI_MIKROBIOLOGIJA"."KOMENTAR",
prekgranupoz("REZULTATI_MIKROBIOLOGIJA"."REZULTAT" ,
"REZULTATI_MIKROBIOLOGIJA"."GRANUPOZ",
"REZULTATI_MIKROBIOLOGIJA"."GRANAKC") AS "PREKGRANUPOZ",
prekgranupoz1("REZULTATI_MIKROBIOLOGIJA"."REZULTAT ",
"REZULTATI_MIKROBIOLOGIJA"."GRANUPOZ") AS "PREKGRANUPOZ1",
prekgranakc("REZULTATI_MIKROBIOLOGIJA"."REZULTAT",
"REZULTATI_MIKROBIOLOGIJA"."GRANAKC") AS "PREKGRANAKC",
prekgranakc1("REZULTATI_MIKROBIOLOGIJA"."REZULTAT" ,
"REZULTATI_MIKROBIOLOGIJA"."GRANAKC") AS "PREKGRANAKC1",
prekukup("REZULTATI_MIKROBIOLOGIJA"."REZULTAT",
"REZULTATI_MIKROBIOLOGIJA"."GRANUPOZ",
"REZULTATI_MIKROBIOLOGIJA"."GRANAKC") AS "PREKUKUP",
brojprekukup(prekukup("REZULTATI_MIKROBIOLOGIJA"." REZULTAT",
"REZULTATI_MIKROBIOLOGIJA"."GRANUPOZ",
"REZULTATI_MIKROBIOLOGIJA"."GRANAKC")) AS "BROJPREKUKUP",
"KB_MIKROBIOLOGIJA"."KOMENTARKB"
FROM (("REZULTATI_MIKROBIOLOGIJA" JOIN "KB_MIKROBIOLOGIJA" ON
((("REZULTATI_MIKROBIOLOGIJA"."KONTROLNI_BROJ")::t ext =
("KB_MIKROBIOLOGIJA"."KONTROLNI_BROJ")::text))) JOIN
("ORG_JEDINICE_Copy" JOIN "VRSTE_PROIZVODNJE_Copy" ON
(("ORG_JEDINICE_Copy"."ORGJED_ID" =
"VRSTE_PROIZVODNJE_Copy"."ORGJED_ID"))) ON
((("KB_MIKROBIOLOGIJA"."VRSTA_PROIZVODNJE")::text =
("VRSTE_PROIZVODNJE_Copy"."VRSTA_PROIZVODNJE")::te xt)))
WHERE (((((((((("ORG_JEDINICE_Copy"."KORISNIK")::name = "current_user"())
AND
("ORG_JEDINICE_Copy"."ODABIR_ZA_IZVJESTAJ" = true)) AND
("ORG_JEDINICE_Copy"."ORG_JEDINICA_UKLJUCENA" = true)) AND
("VRSTE_PROIZVODNJE_Copy"."ODABIR_ZA_IZVJESTAJ" = true)) AND
("VRSTE_PROIZVODNJE_Copy"."VRSTA_PROIZVODNJE_UKLJU CENA" = true)) AND
(("VRSTE_PROIZVODNJE_Copy"."KORISNIK")::name = "current_user"())) AND
("KB_MIKROBIOLOGIJA"."TIP_UZORKA" IS NOT NULL)) AND
(("KB_MIKROBIOLOGIJA"."DATUM_ISPITIVANJA" >=
'POCETNI_DATUM'::timestamp without time zone) AND
("KB_MIKROBIOLOGIJA"."DATUM_ISPITIVANJA" <=
'KRAJNJI_DATUM'::timestamp without time zone))) AND
(brojprekukup(prekukup("REZULTATI_MIKROBIOLOGIJA". "REZULTAT",
"REZULTATI_MIKROBIOLOGIJA"."GRANUPOZ",
"REZULTATI_MIKROBIOLOGIJA"."GRANAKC")) >= REZULTATI_ILI_ODSTUPANJA))
ORDER BY "ORG_JEDINICE_Copy"."ORGANIZACIJSKA_JEDINICA",
"VRSTE_PROIZVODNJE_Copy"."VRSTA_PROIZVODNJE",
"KB_MIKROBIOLOGIJA"."TIP_UZORKA",
"KB_MIKROBIOLOGIJA"."DATUM_ISPITIVANJA"
DESC, "REZULTATI_MIKROBIOLOGIJA"."OZNAKA_UZORKA",
"REZULTATI_MIKROBIOLOGIJA"."BROJ_PROSTORIJE";

Do you see what I mean ?

"(PeteCresswell)" <[e-mail]> je napisao u poruci interesnoj
grupi:hh********************************@4ax.com.. .

Per Zlatko Matiæ:

I supposse it is possible to achieve great progress
even with old technologies such as DAO and ODBC, if some small
modifications
are added such as passing parameters to saved pass-through queries.

But why bother when it can already be done via ADO?
--
PeteCresswell

[Bri]

cr*******@attbi.com wrote:

I've read a lot on this subject, a subject that I'm kind of bummed
about, but can't figure out if I missed the one you're
mentioning...care to state the starting date and title of the
discussion? Was it in this newsgroup? Just looked via google and didn't
find anything that fit the bill, or at least what I expected (the
massive part).

The subject was 'Is Microsoft phasing out Access?'
watch for line wrap:
http://groups.google.ca/group/comp.d...615daf679318cb

--
Bri

[Larry Linson]

<ly******@yahoo.ca> wrote

I started to use ADO in 1998. I have
not been burned with ADO. I do not
know of anyone who has been burned
with ADO. I invite all ADO burnees
to state the nature of their burns and
the specific ADO causes of them
here in CDMA.

Am I wrong in recalling that you had stated here in CDMA that you had
abandoned use of ADO? Perhaps I am also wrong in recalling several who
posted about problems with ADO.

In my limited use of ADO, it wasn't ADO that burned us, but the poor design
practices of the original author (who, judging from the code style, was a
refugee from classic VB and didn't know much about database... like bound
forms, of which there were none; or primary keys, of which there were none
in the SQL database until I asked the DBA to assign one so I could bind a
form in a subform control), but I didn't find it any easier than doing
standard Access-Jet-ODBC-SQL Server and, with the quantities of data
involved in the application, performance was similar. In the applications I
worked on, IMNSHO, ADO was not worth the effort required to learn the
details of a new access method. But, other than that, my only real
irritation was that the criteria of a FIND was limited to a single
expression (situation handled by using an SQL SELECT statement instead).

Larry Linson
Microsoft Access MVP

[Larry Linson]

"Albert D.Kallal" wrote

Well, I don't think ms-access ever was
an enterprise solution anyway.
However, do remember that 99% of
business in the USA is a small business.
So, while you can get all wound up about
big business, they don't represent any
sizeable factor here. So, while enterprise
solutions represents 1% of the business
market, ms-access will happily cover the
99% part.

In a "previous incarnation as a mainframer and minicomputer application
developer", I worked in the "enterprise solution" space. As an Access
developer, I worked with small and medium size organizations and with small
organizations in even larger enterprises which <SUR-PRIZE, SUR-PRIZE,
SUR-PRIZE> had requirements very similar to small and medium sized
businesses. I found the Access development business to be both more fun and
more profitable to me personally than being someone's employee in the
"enterprise world".

I realize that pre-dot-Net, the "enterprise solution space" was the only one
that Microsoft didn't "own", but am really surprised that when they went
after it with dot-Net, they seem to be paying so little attention to the
"little guys" who still need software and aren't satisfied with "canned
software" or "off-the-shelf applications".

Larry Linson
Microsoft Access MVP

[(PeteCresswell)]

Per Larry Linson:

I found the Access development business to be both more fun and
more profitable to me personally than being someone's employee in the
"enterprise world".

Couple years ago, I started dabbling in .NET because one of my clients had begun
a fairly-large project dedicated to replacing one of my MS Access apps with a
VB.NET analog and I had some vague notion of bringing myself up-to-date
toolwise.

After a short and unproductive struggle with the learning curve I sat down and
asked myself what I really had to offer.

My answer was that what I did best was develop applications for people who
needed them sooner than IT could deliver and/or didn't feel they had the time to
spend participating in an excrutiatingly-detailed requirements gathering
process. In the words of an esteemed former coworker: "I don't sell
programming, I sell happiness.".

My rule of thumb for VB6 development (based on developing a single small app
both ways) was that it took three times the manhours that the same project would
take in MS Access. Others - who probably have more experience - have said
it's closer to five or six.

I've never done a project both ways in Access and .NET; but from watching the
abovementioned project for three years I'd have to say that the factor for .NET
is at least ten...and maybe even twenty-something.

That pretty much ended my thoughts of adding .NET to my toolbox - that and the
realization that as a .NET developer I'd be entering an increasingly-commodified
enviromment - i.e. competing more and more with all those English-speaking,
hard-working, educated, intelligent, and diligent folks working for $14/day in
Bangalore...
--
PeteCresswell

[John]

Agree with your timings estimates more or less. problem is clients want
their applications with more sophisticated UIs and access has it limits. I
have myself tried to push it by using controls from dbditech, janusys,
totalaccess and so on but it seems that lately even these guys are loosing
interest and moving to .net.

"(PeteCresswell)" <[e-mail]> wrote in message
news:3b********************************@4ax.com...

Per Larry Linson:

I found the Access development business to be both more fun and
more profitable to me personally than being someone's employee in the
"enterprise world".

Couple years ago, I started dabbling in .NET because one of my clients had
begun
a fairly-large project dedicated to replacing one of my MS Access apps
with a
VB.NET analog and I had some vague notion of bringing myself up-to-date
toolwise.

After a short and unproductive struggle with the learning curve I sat down
and
asked myself what I really had to offer.

My answer was that what I did best was develop applications for people who
needed them sooner than IT could deliver and/or didn't feel they had the
time to
spend participating in an excrutiatingly-detailed requirements gathering
process. In the words of an esteemed former coworker: "I don't sell
programming, I sell happiness.".

My rule of thumb for VB6 development (based on developing a single small
app
both ways) was that it took three times the manhours that the same project
would
take in MS Access. Others - who probably have more experience - have
said
it's closer to five or six.

I've never done a project both ways in Access and .NET; but from watching
the
abovementioned project for three years I'd have to say that the factor for
.NET
is at least ten...and maybe even twenty-something.

That pretty much ended my thoughts of adding .NET to my toolbox - that and
the
realization that as a .NET developer I'd be entering an
increasingly-commodified
enviromment - i.e. competing more and more with all those
English-speaking,
hard-working, educated, intelligent, and diligent folks working for
$14/day in
Bangalore...
--
PeteCresswell

[Sylvain Lafontaine]

I disagree with the notion the .NET is ten times harder then Access. You
are making a comparaison between someone who has many years of experience
with Access, who has probably probably bought many books on it (myself, I
count about 15 books on Access and ADO, I don't know what's the count for
you but I wouldn't bet 20$ that's only one or two) and probably spent many
months studying these books.

When I came from the world of UNIX, VAX assemblies and X-Windows, I don't
remember that learning Access was a particularly easy task. I spent months
trying to decipher the OnOpen, OnLoad and OnCurrent events and learn
idiosyncrasies such as the fact the queries are done before the OnOpen event
for forms but after it for reports, that if you set the record source inside
the OnOpen event, then the OnLoad event is directly called right after that
and no longer at the end of the OnOpen subroutine. When you see people like
Mary Chipman writing nearly a whole book only on the single subject of how
to use unbound forms to circumvent some of the limitations of Access could
hardly be see as a proof of its easiness. If I wanted to, I could add to
this list of *features* of Access until my retreat.

Seriously, I can't tell that Access was easy to learn when I see that I had
to buy 15 books on it and that there are many of its aspects that I still
don't know or are still stumping me. (For exemple, the Access 2002 version
of Litwin, Getz and Gunderloy covers 2 tomes and have more than 2300 pages.
Even with that, there are many aspects that they don't even cover.)

You are making a comparaison between Access and .NET for someone who has
spent many years studying and using Access but instead, you should make a
comparaison for someone who doesn't know Access or .NET at his starting
point; as this is the real situation for newcomers.

The real question is not to know if you have to buy 15 books on .NET and
spent the next months studying them; it is to know for a newcomer who has to
make the decision between buying 15 books on .NET or buying 15 books on
Access and spent the next months on one of these two, then what is his
(best) choice?

I seriously doubt that someone who will have to choose between studying
Access or .NET will find that .NET is ten times harder to learn. In fact, I
won't be surprised if he find that .NET might be, in fact, easier. But even
if his find .NET harder, the broader region covered by .NET - for exemple
the integration of images, the control of transactions, the connection with
the Internet and the absence of many of the illogical idiosyncrasies and
limitations of Access - should easily overcome this.

And before answering me, take a look at the number of books on Access,
Access & Client-Server and ADO that you have in your library.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF
"(PeteCresswell)" <[e-mail]> wrote in message
news:3b********************************@4ax.com...

Per Larry Linson:

I found the Access development business to be both more fun and
more profitable to me personally than being someone's employee in the
"enterprise world".

Couple years ago, I started dabbling in .NET because one of my clients had
begun
a fairly-large project dedicated to replacing one of my MS Access apps
with a
VB.NET analog and I had some vague notion of bringing myself up-to-date
toolwise.

After a short and unproductive struggle with the learning curve I sat down
and
asked myself what I really had to offer.

My answer was that what I did best was develop applications for people who
needed them sooner than IT could deliver and/or didn't feel they had the
time to
spend participating in an excrutiatingly-detailed requirements gathering
process. In the words of an esteemed former coworker: "I don't sell
programming, I sell happiness.".

My rule of thumb for VB6 development (based on developing a single small
app
both ways) was that it took three times the manhours that the same project
would
take in MS Access. Others - who probably have more experience - have
said
it's closer to five or six.

I've never done a project both ways in Access and .NET; but from watching
the
abovementioned project for three years I'd have to say that the factor for
.NET
is at least ten...and maybe even twenty-something.

That pretty much ended my thoughts of adding .NET to my toolbox - that and
the
realization that as a .NET developer I'd be entering an
increasingly-commodified
enviromment - i.e. competing more and more with all those
English-speaking,
hard-working, educated, intelligent, and diligent folks working for
$14/day in
Bangalore...
--
PeteCresswell

[Rick Brandt]

Sylvain Lafontaine wrote:

I disagree with the notion the .NET is ten times harder then Access.

[big snip]

I don't think Pete said "ten times harder". He was estimating that
development times for similar functionality would be ten times as long in
dot-net.

Given the same task and asking a seasoned Access developer to turn out a
finished database app and a seasoned dot-net developer to do the same I
agree that the dot-net solution is going to take a LOT longer to put
together.

I offer no opinion on the superiority of either finished app over the other.
I believe each will have pros and cons, but it I were writing the check
there is no doubt that the dot-net bill is going to have LOTS more zeros in
it and that I am going to be waiting quite a bit longer before I write it.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[David Schofield]

On Wed, 08 Jun 2005 17:10:09 GMT, "Rick Brandt"
<ri*********@hotmail.com> wrote:

Sylvain Lafontaine wrote:

I disagree with the notion the .NET is ten times harder then Access.[big snip]

I don't think Pete said "ten times harder". He was estimating that
development times for similar functionality would be ten times as long in
dot-net.

Given the same task and asking a seasoned Access developer to turn out a
finished database app and a seasoned dot-net developer to do the same I
agree that the dot-net solution is going to take a LOT longer to put
together.

I agree, though this could change ...
I offer no opinion on the superiority of either finished app over the other.
I believe each will have pros and cons, but it I were writing the check
there is no doubt that the dot-net bill is going to have LOTS more zeros in
it and that I am going to be waiting quite a bit longer before I write it.

A big part of the ease of development is the sub-form and its wizards,
see for example Albert Kallal's encomium:
http://www.members.shaw.ca/AlbertKal...000000005.html
If applications don't need subforms they probably can be coded as
easily in other systems.
What puzzles me is why no-one else has developed anything like this
for other systems as some of the grids and controls must have involved
as much development time.

The main drawback of Access (as a FE) is that it the end product isn't
deployable in the way people now expect. Personally I use it for
back-office systems such as data maintenance and reporting rather than
for general users.
David

[(PeteCresswell)]

Per "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>:

I seriously doubt that someone who will have to choose between studying
Access or .NET will find that .NET is ten times harder to learn.

I wouldn't challenge that - especially given the number of books/courses
available today.

What I was saying was that developing a system via .NET would take at least ten
times the manhours that it would in MS Access.

I don't have a whole lot to base that on except:

1) The VB6 ratio (let's say 3:1 absolute minimum) seems pretty solid to me and
everybody I've worked with that does .NET says it takes more manhours than
VB6... and the guy who said it was closer to 5:1 has probably forgotten more
than I'll ever know.... so 3:1 is probably on the low side.

2) A smallish project that I delivered for less that $75k was rewritten by the
client's IT as net-centric (although I cannot swear that they used .NET
exclusively) at a cost of a little over three million dollars. Exactly,
precisely the same functionality - except that it was presented via a Browser
interface.

3) The project that I alluded to in the original post was delivered by Yours
Truly working solo over a period of five years for a cost of a little under
$225,000. Last time I checked, the .NET replacement had 46 people working on
it and had racked up over 23 million dollars.... and should be delivered
sometime Real Soon Now....like by the end of this year. Probably a good 30%
more functionality....maybe fifty.... but not two hundred.
Clearly, projects with many people working on them are less efficient that solo
endeavours - if only because of communication sippage - so the 23 mil comparison
is exaggerated. But by how much? A hundred times? Don't think so....

Also, I take your point that I as an (ahem...) vastly-experienced MS Access
developer can churn out code faster than I could as a .NET newbie.

I've even heard a guy that I brought up in MS Access and who is now a journeyman
..NET programmer say that he could get a screen working in .NET in "just about
the same time as MS Access.".

But I've got to wonder:

1) Just at the screen level, little time-consuming tasks like having to position
each control's label...

2) Having to write a couple pages of code for every combo box to implement
AutoScrolling and AfterUpdate. Yes, they can inherit classes.... but somebody
has to develop those and they have to be made specific to the immediate
situation.

3) And the biggie: having to do the back end on an SQL database - and therefore
develop all those stored procedures which I absolutely positively *know* take at
least 10 times the manhours per procedure as a DAO query done via the visual-UI
query designer.... maybe more.

4) Not to mention having to write the code behind all those datasources...

5) Crystal reports take longer to develop than MS Access reports...period.
I really was entertaining the idea of developing a .NET prototype project - sort
of a synthesis of the most common MS Access projects I do: Home screen, bunch
of parent/child screens for various tables, Admin screen, Report picklist
screen....

I figured that if I could come up with a template that would allow me to churn
out a .NET project in three times the manhours that it took for an MS Access
project, a certain number of users would go for that just to say they have the
latest-and-greatest.

Maybe when my current batch of clients have had their way with me, I'll revisit
that little fantasy.

But I'm still back to: "What do I do that the boys and girls in Bangalore can't
do for $14.00 per day?" And part of the answer is "Develop stuff really
fast." and "Turn on a dime when the client changes their mind or gets a new
idea."
--
PeteCresswell

[Mike Painter]

John wrote:
<snip>

My answer was that what I did best was develop applications for
people who needed them sooner than IT could deliver and/or didn't
feel they had the time to
spend participating in an excrutiatingly-detailed requirements
gathering process. In the words of an esteemed former coworker: "I
don't sell programming, I sell happiness.".

Three years after my Access package was replaced at the local university
pharmacy they were still using parts of it to do things *mandated* by the
government. The first year was a nightmare for them because of features
missing and the awkward implimentation of some needed functions.

The lab watched, then refused to move.

[David W. Fenton]

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in news:eV**************@TK2MSFTNGP15.phx.gbl:

I disagree with the notion the .NET is ten times harder then
Access.

Well, it's a good thing Pete didn't say that -- he said development
takes 10 times as *long*, not that it is 10X harder.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Larry Linson]

Strange, I don't remember any great amount of struggle being required to get
on board with Access, and certainly nowhere near 15 books. I remember Access
2 had a very nice set of manuals, and everything in those manuals was
included in the online help (and, just for the record, it was easy to use
the 16-bit WinHelp and easy to search for and find topics). As I recall, I
had one "general" book (Prague and Irwin's "Access Bible"), one "advanced"
book (The "Access 2 Developer's Handbook" by Litwin, Getz, et al), the
Access 2 manuals, and Help.

I thought it the very easiest programming tool I had ever had to learn, and
I've learned a lot of them since starting in the computer business in 1958.
(Yep, only three years from my golden anniversary.)

If you weren't familiar with "handling events", I suppose, it could have
been a steeper learning curve -- something of a change of view as to how an
application should operate. Even with a long background in mainframe POLs,
though, the idea of responding to events also did not seem a real stretch
when I first encountered it in the minicomputer world.

The object-oriented (or object-obsessed?) world view of dot Net languages,
however, does take some serious changes of view. Everything's an object,
even pieces of data that only used to represent a reservation of storage. I
don't find it at all difficult to imagine doing exactly the same application
in dot Net (whether VB.NET, C#, or COBOL.NET) taking ten times as long as
doing it in Access, even if both are done by "whizzes" in the respective
development environments -- there are soooo many things that Access does
_for_ you that you have to do for yourself, or find something suitable in
some library, or purchase a third-party control to accomplish in dot Net..

That's not to say that dot Net does not have it's place -- the
code-intensive, server-situation, web-based distributed enterprise-level
application. Unfortunately, that's not the kind of application that most of
us do in Access because it is not what our employers or clients need.

Larry Linson
Microsoft Access MVP

[David W. Fenton]

"Larry Linson" <bo*****@localhost.not> wrote in
news:uM9qe.27315$KQ2.14350@trnddc08:

[]

If you weren't familiar with "handling events", I suppose, it
could have been a steeper learning curve -- something of a change
of view as to how an application should operate. Even with a long
background in mainframe POLs, though, the idea of responding to
events also did not seem a real stretch when I first encountered
it in the minicomputer world.
I found events quite puzzling, coming from a sequential, Paradox
programming experience. But I sure loved the engine-level
referential integrity. Cascading deletes were a dream!

I also had trouble with DAO, but that was as much because SQL's
set-oriented thinking did not come naturally to me, and took a while
for me to grasp.

[]
That's not to say that dot Net does not have it's place -- the
code-intensive, server-situation, web-based distributed
enterprise-level application. Unfortunately, that's not the kind
of application that most of us do in Access because it is not what
our employers or clients need.

I think there's a bait and switch going on, in that .NET seems to be
for making distributed (i.e., NETworked) apps, and, specifically,
web-based, browser-hosted apps, while it's being sold as a
multi-purpose development tool for desktop apps. The two
orientations seem to me to be at odds with each other.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Mike Painter]

David W. Fenton wrote:

If you weren't familiar with "handling events", I suppose, it
could have been a steeper learning curve -- something of a change
of view as to how an application should operate. Even with a long
background in mainframe POLs, though, the idea of responding to
events also did not seem a real stretch when I first encountered
it in the minicomputer world.

I found events quite puzzling, coming from a sequential, Paradox
programming experience. But I sure loved the engine-level
referential integrity. Cascading deletes were a dream!

I came from Revelation (Pick based). while it was procedural about 99% of
anything on a form had a ton of "events" attached to it so getting real
events was nice.

It was much easier to move from Rev to Access than from Rev to the very poor
implimentation of Rev in Windows.

Not being able to enter a key in a text box and have it pop the record was a
pain for a while, I still think it should work that way.

Not having the previous record, and the original of the current record
exposed was and is a real pain.

Maybe in a few more years MSFT Basic will catch up to Pick basic in string
handling.
(Although finally having Split and Replace make some of the others much
easier to code.)

[Tony Toews]

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote:

Just to argue one sentence of your posting. <smile>

When you see people like
Mary Chipman writing nearly a whole book only on the single subject of how
to use unbound forms to circumvent some of the limitations of Access could
hardly be see as a proof of its easiness. If I wanted to, I could add to
this list of *features* of Access until my retreat.

I don't know why you'd want to use unbound forms except in some
special circumstances. Granted I'd like to see independent combo
boxes on continuous/sub forms and independent unbound fields but other
than that bound forms work very well for me.

Tony

--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[(PeteCresswell)]

Per Tony Toews:

I don't know why you'd want to use unbound forms except in some
special circumstances.

My theory is that unbound forms help to make the app more bulletproof.

Instead of somebody sitting on a record - and maybe turning off their PC or
something, the app just hits the DB for a fraction of a second to populate the
form and then it's out of the back end.

For me they also facilitate "Browse" and "Edit" modes with "Save" and "Cancel"
by enabling the programmer to do quite a bit more cross-checking/validating
before anything goes out to the back end.

Maybe this is all BS - but I've been doing unbound forms for so long that
they're second nature (i.e. quick and easy to clone...) whereas every time I've
tried reverting to bound forms the users have come up with a requirement that
broke my little scheme. OTOH, maybe I just haven't developed the skill set
needed to deal with some of those situations in bound forms...
--
PeteCresswell

[(PeteCresswell)]

Per (PeteCresswell):

but I've been doing unbound forms for so long that

I think I got off on the unbound forms tangent developing for SQL Server back
ends. They seemed to fit more conveniently with the idea of stored procedures
to deliver the data - often via multi-file ADO recordsets so we'd only have one
round-trip to the server to load a screen with, say, seven child tables on it.

--
PeteCresswell

[Larry Linson]

If you went to unbound forms, why would you bother to use Access -- why not
move on to classic VB? Classic VB pretty much _had_ to use unbound forms
because its binding was not nearly as good as Access' binding. The big
advantage of using Access over VB for database development was the richer
event model for database.

Most people I know used some unbound forms when they were just starting
because they couldn't easily figure out how to do what they wanted. Some
went on to "grok the Access way -- bound forms" and rarely, if ever, use
unbound forms any more; but the use of unbound forms kept others from
learning much more about Access, so they never really learned Access and,
thus, never were able to enjoy the advantages that Access and bound forms
gave them in development time and effort.

Larry Linson
Microsoft Access MVP

"(PeteCresswell)" <[e-mail]> wrote in message
news:cn********************************@4ax.com...

Per (PeteCresswell):

but I've been doing unbound forms for so long that
I think I got off on the unbound forms tangent developing for SQL Server

back ends. They seemed to fit more conveniently with the idea of stored procedures to deliver the data - often via multi-file ADO recordsets so we'd only have one round-trip to the server to load a screen with, say, seven child tables on it.
--
PeteCresswell

[ljubo lecic via AccessMonster.com]

I am the one who has been developing apications under ORACLE for a long
period of time.ORACLE Aplications development environment is very strong
(SQL*Forms and ORACLE Designer) and allows the programer to do the
mirracles.
I made this remarks because I got very familiar with ACCESS in the last
six months and I think that I am relevant to say something about ACCESS.

1. As an aplications development tool ACCESS is FANTASTIC !!!.(That is
the primary purpose of ACCESS)
2. It is often said that ACCESS is weak as a database. I would say That
it is very strong database IF YOU USE IT WHERE ACCESS IS INTENDED
TO BE USED!!!( JUST DON'T USE IT INSTEAD ORACLE OR SQL*SERVER )
3. There are lot of talks going around comparing ACCESS with other tools,
talks about new tools from MICROSOFT etc.I am certenly not going to
waste my time learning new tools. I can do anything in ACCESS
(with a help of VB code when necessary) as a front-end.The back-end
can be choosen appropriately.(Often ACCESS itself is enough).
4. I have strong feeling that some people oppossing ACCESS just
don't understand the principles of RAD tools and would prefer to
go back to COBOL times.
5. I am convinced that ACCESS deserves very much to be strongly supported
by MICROSOFT as it is the fantastic tool( for those who understand it)
..BUT I won't be surprised if there are bad news too because history
teaches us that being good or the best doesn't neccerelly mean
existance on the market (MOTOROLA CPU-s or BETAMAX video standard)
There are often forces other than the pure quality which participate
in a decision making process.

[Lauren Wilson]

On Sat, 28 May 2005 17:13:59 -0600, "Albert D.Kallal"
<Pl*******************@msn.com> wrote:

"John" <Jo**@nospam.infovis.co.uk> wrote in message
news:eb**************@TK2MSFTNGP14.phx.gbl...

What future does access have after the release of vs 2005/sql 2005? MS
doesn't seem to have done anything major with access lately and presumably
hoping that everyone migrates to vs/sql.

Any comments?
First, ms-access makes a great front end to sql server. So, you kind of have
to consider ms-access a developers tool like c++, or VB, or vb.net.

Remember, with sql server, or oracle, you can't create a form, or even a
user interface. So, if you move to sql server, what will you make the forms
with?

Uh ... perhaps VB.NET? C#?

This is the crux of the issue. Assuming I am correct (always a leap
of faith), based on the blizzard of stuff about VB.NET, ASP.NET, C#,
et. al., compared to the relative dearth of RECENT, "exciting"
pronouncements from MS on the "big plans" for Access, it DOES leave
many of us with the impression that MS is de-emphasizing Access --
despite that ONE article in Access Advisor. Perhaps us Access
old-timers are just perceiving threats to our knowledge base that are
caused by paranoia. However, it would be a huge comfort if MS would
issue an OFFICIAL statement that EXPLICITLY says: "We have big,
exciting plans for enhancing Access as a development platform.
Specifically, we will add this kind of new functionality in support of
that goal: _________________________"

I have attempted to find comprehensive information on how one could
convert an EXISTING, complex Access application to VB.NET -- perhaps a
well written book. To date, I have found exactly one, published by
Microsoft Press: "Programming Microsoft Visual Basic.NET for Microsoft
Access Databases." As far as I can tell, it fails to answer the
number one question in my mind that caused me to buy the book: WHY
would anyone WANT to convert an existing, widely deployed Access
application into VB.NET? IOW -- is there any value in doing so? The
basic question: Is access near the END of it's life cycle (as a
development tool) or not?

This may not be the correct venue for that question. Nevertheless,
all competent discussion on that issue will be much appreciated.

ms-access is primarily a developer tool that lets you build a interface. You
can build this interface, and connect to the JET engine, or connect to sql
server. Thus, you really can't outgrow ms-access in terms of users. It
would be wrong to think as ms-access as a database (it is not). Ms-access is
a tool that lets you build applications, and lets you CONNECT to a database
engine of your choice. So, if you got a oracle database, ms-access is still
a great tool to use, and connect to that database.

As for new features? Well, each version of ms-access tends to bring us along
for the Microsoft ride for technology. When class objects became all rage in
programming circles, we got that feature added to access 97.

You can read about class objects and why you would use them here:
http://www.members.shaw.ca/AlbertKal.../WhyClass.html

When Microsoft came out with ADO (active data objects), then for access
2000, we got ado added to ms-access. When ms-access 2002 came along, XML was
all the rage, and we got even better support for XML in access 2003. And,
access 2003 also let you use share point services.

Further, while you can't write web services in ms-access, you can certainly
CONSUME web services. The reason why you can do this is that Microsoft
released the soap add in tool kit for ms-access. So, if you want to use .net
services via SOAP, or use things like XML...you now can. Hence, you can
consume .net web services with ms-access. So, from a developers point of
view, ms-access gets most of the new technologies that Microsoft comes out
with. They have consistently for the last 10 years added new technologies
to ms-access that they are using for building software.

If you look at the above additions to ms-access, you can clearly see that as
Microsoft comes out with new technologies, they have been adding them to
ms-access. And, if you think about the above features, MOST are not actual
database features, but simply additions to what developers would expect with
a developers tool.
Nevertheless, there APPEARS to be a LOT of emphasis by MS on using
tools like VST, VB.NET, etc, for creating the user interface to ANY
back end database. Over the last few weeks I have spent a lot of time
searching the MS web sites for articles on using Access to develop
more Office integration, specifically for Office 2K3 and Word 2003
automation. Perhaps I'm just not using the search engines correctly
but I'm having trouble finding a quantity of such articles one would
expect for a development platform as mature and comprehensive as
Access 2003. Over 90% of the search engine hits end-up talking about
anything BUT Access -- EVENT when the word "Access" or "Microsoft
Access 2003" are specified for the search criteria.
So, I never really thought of ms-access as a database, and the fact that you
can (and should) choose the appropriate database engine for your task at
hand never really changed the fact that you can use ms-access with your
database of choice.
True. Nevertheless, it appears that tools like VB.NET are ATTEMPTING
to unseat Access and VBA as the user interface tool of preference from
a Microsoft strategic planning perspective. I would LOVE for someone
to banish these fears in my mind.
If you want to pick oracle as your database, you can. However, you
can't build a form with a oracle database..and you can with ms-access.
.... but you can ALSO do so with VB.NET -- a tool that Microsoft IS
emphasizing all over the place. Go figure.
So, you most certainly
can use ms-access to build the application, and use oracle as the database
for this ms-access application. ms-access is thus a tool to 'access' a
database, but ms-access is not really a database.

As for other new features in a2003 that I like and use? Well, you can change
the font size in the sql view (I really like that feature). Another feature
is ms-access now supports themed controls. This makes your "old" software
kind of look new. Here is some screen shots of old vs new. (the only thing
done was turn on themes).

http://www.members.shaw.ca/AlbertKal...heme/index.htm

There is some more screen shots here:

http://www.members.shaw.ca/AlbertKal...erFriendly.htm

Another feature is automatic
error checking for common errors in forms and reports.
Error checking points out errors, such as two controls
using the same keyboard shortcut, and the width of a report
being greater than the page it will be printed on.
Enabling error checking helps you identify errors and
correct them.

The Smart tag help appears in reprot desing also is nice.

And, when you change a field property in the table design, you can have
that change prorogate thought out the application (forms and reports will be
updated to reflect this change).

There is a bunch of other features I don't care...nor use in a2003. However
Microsoft continues to work on the next great version, and if the above
history is any indication of the path of the product, then we will continue
to see new features..and new that MS comes out with integrated into that
developers product.

I hope this means that Access will continue (for the mid term at
least) as the BEST user interface tool for database driven
applications.

[Lauren Wilson]

On Sun, 29 May 2005 21:35:26 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in news:uw**************@TK2MSFTNGP15.phx.gbl:

By "recordsets", I'm referring to the DAO and ADO implementations
of recordsets in comparaison with the datasets of the .NET
framework. In ADO.NET, the recordsets are so different from their
DAO and ADO counterparts that MS has changed their name to
Dataset.

My statement about "recordsets" may look strange at first but if
you take a look at ADO.NET, the answer will become obvious. This
is why I didn't give any further explanation in my other post.

You sound a lot like a garden-variety moron who selects the most
recent Microsoft technology just because Microsoft says it's coming
next. Those who did that with ADO after the release of Access 2000
got badly burned, so I think it highly unlikely that any experienced
Access developer would be anxious to start on whatever Microsoft
says is the latest and greatest, and that includes all the .NET
lunacy, which really isn't designed for the same problem space in
which Access excels.

I HOPE this is true. However, a diligent researcher is easily
overwhelmed with indications to the contrary when searching MS
knowledge bases for RECENT articles on using Access 2003 to create
mission critical apps. Please prove me wrong.

[lylefair]

Larry Linson wrote:

<ly******@yahoo.ca> wrote

> I started to use ADO in 1998. I have
> not been burned with ADO. I do not
> know of anyone who has been burned
> with ADO. I invite all ADO burnees
> to state the nature of their burns and
> the specific ADO causes of them
> here in CDMA.

Am I wrong in recalling that you had stated here in CDMA that you had
abandoned use of ADO? Perhaps I am also wrong in recalling several who
posted about problems with ADO.

Yes, you are wrong. Perhaps, you are thinking about my posts about ADPs.

[(PeteCresswell)]

Per Lauren Wilson:

WHY
would anyone WANT to convert an existing, widely deployed Access
application into VB.NET? IOW -- is there any value in doing so?

A few that came to my mind:
-------------------------------------------------------------------
1) Somebody needs to bill about a bizillion more hours to that client.

2) The client does not want to live with the MS Access version thing hanging
over their head. i.e. Maybe the app is so widely deployed in so many divisions
that when a new version of MS Office and the attendant new version of Access
comes out that just a bunch of blind installs will render the app un-runnable by
most users.

3) The client wants to deploy the app over the web.

4) The client wants to run the app over the web.

5) The client's IT people are starting to jump ship because they want jobs that
will expose them to more cutting-edge development environments.
--
PeteCresswell

[(PeteCresswell)]

Per Larry Linson:

If you went to unbound forms, why would you bother to use Access -- why not
move on to classic VB?

Now that you mention it, VB was another driving force in my choice. At the
time, I thought that I might as well write this stuff as much like a VB app as
possible just so I can transition myself if VB work comes my way.

Various clients wanted MS Access because of:

1) The notion that they could take over maintainence of the app once I was done.
Fallacious, IMHO - but that was their perception.

2) It's reputation for fast turnaround/delievery.

3) Back in the End User Support days, MS Access was a sort of "official" tool
for end-user projects - as opposed to VB.

Personally, if a client wants cheap and fast I'd still use Access because the
one trial project I did both ways took three times the hours to do in VB as it
did in Access - and the analysis had already been done. Others who have
probably forgotten more than I'll ever know have said the factor is more like
five or six.

The querybuilder, reports, text boxes with the attached labels that follow them
around, subforms, ComboBoxes' AfterUpdate().... and so-forth.
Little things that add up manhourwise.

Finally, because Access what I do. They could probably find a more skilled VB
developer for less dollars per hour.
--
PeteCresswell

[David W. Fenton]

"(PeteCresswell)" <[e-mail]> wrote in
news:ii********************************@4ax.com:

Per Lauren Wilson:

WHY
would anyone WANT to convert an existing, widely deployed Access
application into VB.NET? IOW -- is there any value in doing so?

A few that came to my mind:
-------------------------------------------------------------------
1) Somebody needs to bill about a bizillion more hours to that
client.

2) The client does not want to live with the MS Access version
thing hanging over their head. i.e. Maybe the app is so widely
deployed in so many divisions that when a new version of MS Office
and the attendant new version of Access comes out that just a
bunch of blind installs will render the app un-runnable by most
users.

3) The client wants to deploy the app over the web.

4) The client wants to run the app over the web.

5) The client's IT people are starting to jump ship because they
want jobs that will expose them to more cutting-edge development
environments.

Don't you agree that most of these are not particularly *good*
reasons to avoid Access?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Rick Brandt]

"(PeteCresswell)" <[e-mail]> wrote in message
news:ii********************************@4ax.com...

Per Lauren Wilson:

WHY
would anyone WANT to convert an existing, widely deployed Access
application into VB.NET? IOW -- is there any value in doing so?

A few that came to my mind:
-------------------------------------------------------------------
1) Somebody needs to bill about a bizillion more hours to that client.

2) The client does not want to live with the MS Access version thing hanging
over their head. i.e. Maybe the app is so widely deployed in so many
divisions
that when a new version of MS Office and the attendant new version of Access
comes out that just a bunch of blind installs will render the app un-runnable
by
most users.

3) The client wants to deploy the app over the web.

4) The client wants to run the app over the web.

5) The client's IT people are starting to jump ship because they want jobs
that
will expose them to more cutting-edge development environments.
--

IMO there is no 1, 2, 3, or 4. it is ALL 5.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Lauren Wilson]

On Mon, 13 Jun 2005 02:16:35 GMT, "Rick Brandt"
<ri*********@hotmail.com> wrote:

"(PeteCresswell)" <[e-mail]> wrote in message
news:ii********************************@4ax.com.. .

Per Lauren Wilson:

WHY
would anyone WANT to convert an existing, widely deployed Access
application into VB.NET? IOW -- is there any value in doing so?

A few that came to my mind:
-------------------------------------------------------------------
1) Somebody needs to bill about a bizillion more hours to that client.

2) The client does not want to live with the MS Access version thing hanging
over their head. i.e. Maybe the app is so widely deployed in so many
divisions
that when a new version of MS Office and the attendant new version of Access
comes out that just a bunch of blind installs will render the app un-runnable
by
most users.

3) The client wants to deploy the app over the web.

4) The client wants to run the app over the web.

5) The client's IT people are starting to jump ship because they want jobs
that
will expose them to more cutting-edge development environments.
--

IMO there is no 1, 2, 3, or 4. it is ALL 5.

PRECISELY my concern in a nutshell! Thanks Rick. Is it or is it not
true that MS intends to keep (make) Access a CUTTING EDGE development
tool?