423,846 Members | 2,048 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 423,846 IT Pros & Developers. It's quick & easy.

Questions about Access from a .NET/C++ developer

P: n/a
I am a .NET/C++ developer who is supposed to do some work with Access.
I do not know much about it except for the DB part.
Questions:

*1*
I am looking for INTENSIVE books to get quickly up to speed.
I like books with practical exercises, and also with test questions (like
cert books)

*2*
Some explanation about where Access fits in the big picture -
what you typically should use Access for and where you
should use something else. (I am thinking of the GUI part)

*3*
Are there any interesting technologies I should look at in connection with
Access
(.NET, Scripting, Open Source...)
I think its usually scripted with VBA - Can I use Python instead?

*4*
Should I use the built in DB or SQL Server?
(Don't think performance is an issue)

*5*
Any newer developments I should be aware of?

*6*
Good sources of free existing solutions I can work from.

Thanks
Olav

Nov 13 '05 #1
Share this Question
Share on Google+
20 Replies


P: n/a
"Olav.NET" <Ol******@hotmail.com> wrote in message
news:41*********************@news.skynet.be...
*2*
Some explanation about where Access fits in the big picture -
what you typically should use Access for and where you
should use something else. (I am thinking of the GUI part)
ms-access is a RAD database front end development tool. (RAD = Rapid
Application Development).

This means that ms-access is designed for making CRUD forms to a database of
your choice (CRUD = Create, Read, Update , Data).

So, ms-access is not really a database, but only a front end tool to create
forms and a interface to a database engine.

For example, you can't create forms and a interface with sql server, or
Oracle, or Mysql.

However, you can use ms-access as a tool to development forms and an
application to work with sql server, or Oracle, or Mysql, or JET etc.

So, ms-access is a tool that lets your interface, and build a UI to
edit data. In this regards, it is a good 3 or more times less work to do the
equivalent in something like VB, or VB.net. So, a project in ms-access that
cost $8000 will cost you about $25,000 or more to develop in vb.net. (some
users rate the time factor larger...but it is at LEAST several times more
costly to development a CRUD application in VB.net).

For example, the following screen shots of grids and being able to edit data
can be done with about 1/10 the amount of coding and setup you have in
traditional environments:

http://www.members.shaw.ca/AlbertKal...icles/Grid.htm
Typically, most applications written in ms-access use the JET data engine.
JET is the file based database engine. (you can use that engine, or choose a
server based system to use with ms-access like sql server).

So, it is important to realize that ms-access is a development tool like VB
etc, and is not a database. You write business applications in ms-access,
and
choose a data engine that you want ms-access to work with. As mentioned, for
general business applications that are CURD, then ms-access is at least 1/3
the
cost of developing applications then that of VB, or "general" type
development environments.

*3*
Are there any interesting technologies I should look at in connection with
Access
(.NET, Scripting, Open Source...)
I think its usually scripted with VBA - Can I use Python instead? .NET
As for .net, ms-access cannot be used to write web services, but the SOAP
add in for ms-access is available,and this most certainly lets you consume
web services in your applications that you create with ms-access.
Open Source
You can certainly use ms-access as front end to MySql. And, there is likely
more source code posted for ms-access applications by a LONG SHOT as
compared to any other RAD database tool in the market place.

I think its usually scripted with VBA
Yes, but script is a poor choice of words. VBA for ms-access = VB6. (same
compiler is used). That means you have the same syntax as VB6, and can even
create and use class objects with ms-access. However, what makes ms-access
so different then VB6 is that the forms (object) model is VERY different
from
VB6 (and, since a lot of things happen around forms..then ms-access is
different then VB6..but this mostly only due to the forms model!!).

The forms and objects model in ms-access has a FAR HIGHER learning curve
then does VB6, so be prepared to spend time learning this object model (if
you don't, then you will not realize the increased productivity that
ms-access has over products like VB, and vb.net).
*4*
Should I use the built in DB or SQL Server?
(Don't think performance is an issue)
This choice is going to depending on many factors. If you have a high user
load, then sql server might be a better choice then the built in (JET)
engine. You can continue to use ms-access, but the data will thus
be on the server. The answer here is really going to depend on
many factors. If you only got 4, or 6 users, and a standard
office network, and small tables in the 100,000 record range,
then JET is more then adequate for the job.


*5*
Any newer developments I should be aware of?
Well, unlike VB6, ms-access continues to be upgraded, and we continue to get
new versions (released with each new version of office). So, for example we
now have XML support built into ms-access. And, just got themed controls.

*6*
Good sources of free existing solutions I can work from.


The best starting point I can think of is here:

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

Nov 13 '05 #2

P: n/a
Olav,

The contrarian view:

If you have sufficient expertise in programming databases with .Net,
Access will likely not be a step forward for you. Certain things you
can do automatically in .Net would require a lot of programming in
Access, and vice versa.

Access is billed as RAD, but, in my experience, it is a net gain only
for simple projects where professional results are not required. When
you try to use Access to deliver a professional quality application,
the effort required approaches, and may surpass, the effort required to
deliver a similar result in .Net.

In fact, many of the RAD features touted in Access get in the way of
professional development. Take the form event model, for instance. It
is great for quick and dirty work: slather a bunch of code in there,
and you're up and running fairly quickly. However, time and time again,
I find that debugging form events takes up a major amount of my ongoing
testing budget. So much so, that my general development strategy has
been to not use events where possible, and design my own simpler and
more predictable work-arounds.

..Net has a MUCH better development methodology, and vastly superior
language features, to VBA. (Note that VB.NET, or a subset, may become
the scripting language for Access in the near future. If so,
development opportunities in Access will dramatically open).

Access is an extremely mature product. It has a lot of baggage, and
built-in limitations because of that baggage (notably, poor web
support). So much so that I believe a good component developer in .NET
could craft a set of flexible, reusable data and form components, based
on a far simpler event/messaging model than Access forms have, and run
rings around the average Access developer in terms of productivity.

The only thing that Access has that would be truly hard to replace is
the report generator, but SQL Server Reporting Services is just good
enough, and within a few versions, should be more than up to the task.

As far as free solutions, you will notice tons of code fragments, but
very few complete components (add-ins, etc). This is because Access
does not lend itself to component development. Because it is hard to
share code in a meaningful way (you can't easily make DLLs or COM
components), you will find very few areas where there are existing
well-formed solutions to a problem class that you can simply plug in
and use. What you will find is a lot of work-arounds to limitations in
Access. When you see all the smart people spending so much time fixing
their program's limitations, you may be forced to ask yourself, if why
use the program at all?

Again, Access is a closed, scripted environment. .Net is a
fundamentally more open, component-based environment. Two years of
effort devoted to learning Access will produce limited results in a
client-server architecture that is becoming outmoded. The same two
years devoted to .Net will produce a far greater win, allowing you to
develop components that leverage both web services, the real future in
applications, and client-server.

-Ken

Nov 13 '05 #3

P: n/a
"Ken Ismert" <ki*****@texassystems.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
Access is billed as RAD, but, in my experience, it is a net gain only
for simple projects where professional results are not required.
That is not a fair statement at all.

What exactly do you mean by professional results?

The worst, and I repeat the worst applications I have seen over the
years have been applications written in VB, and not ms-access.

As for seeing poorly designed VB.net applications, the
sample applies. The VB.net applications custom written
for small business that I seen been just terrible.
And, a few other projects I know of failed!!!

Professional results are that of having good designs, and good
developers, and yes, good tools. Ms-access has been around
for a very long time indeed, and has the VB6 IDE and
programming language. It would be silly to say that VB6, or
ms-access somehow does not produce professional results, but
somehow vb.net does? That is a statement of ignorance.

Ms-access is not a OO environment, but is most
laughable that you stand here and tell me that professional
results are harder to obtain in ms-access then that of VB.net.

Why is this so? For what reason?

I am going on the record and telling you it is the reverse!!! Results and
lack of consistency is MUCH worse in VB.net then it is in ms-access.

If you give me two poorly written applications, one in ms-access, and one in
VB.net, the one in VB.net is MUCH WORSE!! I repeat, MUCH
worse!!

Take a well written business crud application written in VB.net, and
that of one in ms-access, and users will find little, if any differences in
terms of useable, or "professionalism" as you state.

The main reason for this (and my experience as consultant) bears this out is
that the vb.net forms model does not have the consistence of how to
approach and solve problems. So, you get one form with different navigation
then the next form. You get one form with navigation buttons, but now
in a different place.

You get one form that saves data in a different way then the next. In
ms-access the forms model for DATA editing is already designed
for you. Thus, a new developer, or a professional developer gets
the same consistency throughout the application.

Now, fair is fair, if your developers are not consistent, then we likely
should not blame the tools. However, this concept applies to vb.net,
assembler, or ms-access. However, for editing data, ms-access does have a
consistent design approach, and vb.net does not. The fact still remains that
you get a more consistent design in ms-access then you do in vb.net
when it comes to editing of data.

If your developers adopt some approach, there is nothing to say that the
next person who comes along will not change how a form works. Again,
in ms-access you can make a mess of data updating, but at least there is a
proper way to use the built in events and how the form works. You
simply can not ignore that this results in a more consistent design, and
further more consistent design among DIFFERENT developers in ms-access.
With vb.net, how the UI, and how data is updated is completely at the whim
of the developers. Again, I will admit that this freedom can be good, but
more often then not..it creates a mess.

This is equivalent to saying we
should get rid of sql because it forces developers to work with data
in a consistent way. Sure, it does restrict the developers choice when
you force sql on them..but then the consistent methodology to using sql
pays off in the long run. So, some restrictions and constraining of
developers is a GOOD THING, and you get better results with
these types of restrictions. Consistent data editing and the
forms object model in ms-access is a perfect example of this
concept in action.

If you have good UI for the application, then ms-access is just fine. While
the following article of mine shows screen shots in ms-access, the
information
supplied also applies to any other development tool(s) you choose to use.

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

I see little, or no problems as to why you could not, or do not get
"professional"
results in ms-access.

And, more amazing, is that more and more developers are leaning that a
way cool funky screen is not better then a simple clean data entry screen.
The explosion of the web is showing that a clean simple interface wins
time and time again over that of "too" rich interface loaded up with
all of hidden menus and features anyway.
..
Uses tend to be MORE happy with a clean simple interface.
When
you try to use Access to deliver a professional quality application,
the effort required approaches, and may surpass, the effort required to
deliver a similar result in .Net.
It is not even close. As I mentioned, that factor of 3 times was
conservative.
Take the form event model, for instance. It
is great for quick and dirty work: slather a bunch of code in there,
and you're up and running fairly quickly. However, time and time again,
I find that debugging form events takes up a major amount of my ongoing
testing budget.
I can only say that your developers likely did not take the time to learn
the
forms event model. This is the same old story of developers blaming their
tools, and lack of knowledge.

I for example can't believe the number of developers that don't know
when to use on-load vs on-open event. These two events are very important
in ms-access, and how they are used. And, further, having two events for
loading a form also gives one more consistent development approach to
solving TYPICAL problems that crud business applications have.

For example, the on-open of a form is used to test conditions, and certain
things that would CANCEL the form load. Thus, things like record locking
and other conditions can be checked here. And, by the way, even vb.net
does not have a separate on-load vs on-open event to use!!

Once the all of the conditions are meet in the on-open, then all of the
setup code, var initializing etc occurs in the forms on-load event.

What a brilliant concept ms-access has here. So, in the on-open you
can look at, and examine a text box control and recordset data, but it
is too soon to modify the data. You have to use the on-load to do this!

Now, why is this a big deal?

Well, two reasons:

1), a ms-access developer will know that all code that checks to *prevent*
the form from lading will in the in on-open event. (where does a vb.net
developer look for this code?? - please do tell me??And, also tell me
how you cancel the form load in the first place??).

This is means that as a developer, you have a better, and finer division of
the process that occurs when a form opens.

2) And, since it is too soon to modify data, then code that sets up
variables, and sets up controls (defaults etc) on the form will HAVE TO be
in the on-load event.

Once again, this means a developer will know WHERE to look
for the code that sets things up for the form. (in the on-load event).
So, the on load event is for code that sets up variables, sets up
control boxes etc.

Again, this is not only a cleaner design then vb.net forms, but you have
two distinct locations for your code that does NOT exist in vb.net.

Question:

In a vb.net application, where will an average developer find the code that
cancels the form load ? This is painful and hard to do!!

And, where will a developer find the code that initializes variables and
controls on the form? (ok, this one is easy: either all over the place,
or even worse, both the code for prevent the form open, and setup
code is going to be in the forms on-load event. Worse, often
a solution is to have the CALLING code that creates the instance of the form
test, and check to prevent the form load (this is horrible development
approach!!). The code belongs with the FORM...not the calling code!!!
.......bad bad vb.net!! ...spank you!!

Two separate events are needed here..and they are missing!!
So much so, that my general development strategy has
been to not use events where possible, and design my own simpler and
more predictable work-arounds.
This is a classic developer issues. Are you willing to take more time
to learn the product, or not? Do you trade more understanding for more
developer productivity or not?

I mean, look at all the different types of collections
available in vb.net (hash code, indexed, non-indexed etc, sorted). And,
in addition to all those new collection types, you also have for good
measure a "legacy" collection object that behaves just like
the existing collection object in VB6 (or, ms-access..as I use those
collections a lot!!). You can ignore all these new features of vb.net, and
NOT take the time to learn about the hash-code collection, or
indexed/sorted collection n vb.net, but the end result is less productively
on your part.

This same reasoning applies to using ms-access forms,
and if you don't take the time to learn them..then you don't get
the benefits.

It is only by learning the more complex objects models are you
going to increase your development rate. The same applies to the
forms object model in ms-access (I warned the OP about this
in my other response). Now, while vb.net has a much rich
object model for many of its objects, it DOES NOT have
a forms object that is optimized and designed solely for
editing of data. Thus, you get a much HIGHER developer
productivity WHEN you are writing an application that is
to edit data. If vb.net was better then ms-access for
editing of data, then bb.net would be a CRAPPIE
general development tool saddled with kinds of extra events
and stuff that non data centric applications do not need!!
vb.net would be disaster of a product if it was better
them ms-access to edit data.
.Net has a MUCH better development methodology, and vastly superior
language features, to VBA. (Note that VB.NET, or a subset, may become
the scripting language for Access in the near future. If so,
development opportunities in Access will dramatically open).
The question is how much gains do you get in productivity here? For MOST
business applications, ms-access is far better, and I mentioned runs
ABSOLUTE circles around vb.net.

The widespread adoption of OO
has not really had a huge impact on programmer productivity in most SMALLER
applications. What OO has done has allowed developers to MANAGE
increasingly complex applications with greater ease (read: better for
LARGER
and more complex applications!). The average business is NOT writing Excel,
or
creating a word processor, and thus the benefits of OO don't help very much.
So much so that I believe a good component developer in .NET
could craft a set of flexible, reusable data and form components, based
on a far simpler event/messaging model than Access forms have, and run
rings around the average Access developer in terms of productivity.
Sorry, that is just not the case. And, the projects I seem in both vb.net
and ms-access bear this out. It is just not even close, as much as
many want to believe. I really do wish vb.net was close to ms-access
in this regards. However, our believes, or hopes on this issue does
not change the brutal realty, and facts as they are!

It is like you are telling me in place of using auto-cad to design cad
drawings, that you should use vb.net? This is all about using the right
tools for the right job. vb.net is a GENERAL development platform, and as
such is a incredible development platform. However, just like vb.net is not
for making cad drawings, it is also NOT primary designed to build forms that
edit data (and ms-access is). I am trying hard here to understand what part
of this concept you don't understand here?

You are not nearly as productive to build forms that edit data in vb.net as
you are in ms-access. When products like dbaseII, and FoxPro etc. came out,
they caused a revolution in the pc business because all of a sudden, the
developer productivity to write applications that edits data was on the
order of
magnitude of traditional development tools. It did not make sense back then
to
code an application in a plane Jane BASIC, or c, or c++ language.

Today, we still have a basic programming language for windows, and that is
vb.net. However, this programming system does not compare to the production
that you get with tools designed specially to edit data in forms. Nor, does
it
compare with a CAD system to make drawings. It is not that a developer
using ms-access somehow types faster, it is just that the product is
designed
to do certain tasks better then a general development system like vb.net.

However, there are good number of reasons to use vb.net, (and you pointed
out
a few). I do believe that when the requirement goes beyond one developer, or
budgets exceed that of about $35,000, then vb.net is a better choice. This
is because the development process with larger complexity and a larger code
base needs to scale to using more developers. And, thus the OO approach
of encompassing code and rules then also beings to pay off on projects of
these sizes. You don't need a big huge Mac truck to deliver one small
parcel across town. However, as things get larger, and greater
in size, eventually, you need that big rig to move your stuff. This concept
also applies to vb.net.

The other area where traditional developer platforms is a better choice then
ms-access is in terms of wide spread distribution. If you are distributing
an application to 200,000 users, then you can easily spend $10,000
on just a screen and a grid control to work exactly the way you want. For a
in
house application, you have no such luxury, and likey the WHOLE budject
for the project is going to only $10,000. Further, those general tools have
BETTER package and deplyment tools, and as they should!!

(one of my ms-access applies was competed in less then 3 months, has 160
forms, and about 27,000 lines of code. In vb.net, you can multiply the time
by a factor of 3, or 4, and you get year of time to complete this project.

And, speaking of development advances, I should point out that
ms-access developers for 10 years now have enjoyed x-copy development.
The vb.net community is just now realizing how great of concept this is! On
the
other hand, you do have to hope that the CLR is present on those
machines, and the right one is present. And, of course we assume that
future releases will NOT break your application!!

Just to be clear, I am strong believer in the CLR concept, and the ms-access
model
proves this in practice. All we just have to do is ensure that the right
version of office is installed (for ms-access), or the right CLR, and then
the rest is x-copy. This is real nice!! I don't need to be sold on this
concept,
since we had it for a very long time.

The only thing that Access has that would be truly hard to replace is
the report generator, but SQL Server Reporting Services is just good
enough, and within a few versions, should be more than up to the task.


Actually, there is a zillion things. For example, how do you open a form to
a invoice record?

strWhatInvovie = inputbox("view what invoice")

docme.OpenForm "frmInvoice",,,"invoiceNum = " & strWhatInvoice

I count 2 lines of code. What is your solution in vb.net. I can really write
on for 100's of pages here.

Still no multi-column combo box, still not combo box with a "not in list
event" (how on earth do you write code to bring up a form to
add ONE new item to the combo box..and continue? We got an
event JUST for this task..."not in list"). And, still no sub-forms,
still no continues forms. (this list is ad-nasm long here). I
simply going to stop here.

vb.net is not auto-cad, nor is vb.net a system to build applications
that are data centric like ms-access is.

I would be crazy to build a game in ms-access, but certainly it DOES
makes sense to write games in vb.net. (some argue that c++ is still better
yet!!).

For a very large portion of in-house business applications, ms-access is a
far
better choice then is vb.net.

I am perfectly willing to admit that for a lot of in-house applications,
vb.net is a better choice then ms-access also!. However, at least I
have taken the time to figure out when the choice between the tools
should be made. If you don't make that choice..you are wasting
lots of money that could go to help other projects..or even
needy people around the world..

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

P: n/a
"Ken Ismert" <ki*****@texassystems.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
Olav,

The contrarian view:

If you have sufficient expertise in programming databases with .Net,
Access will likely not be a step forward for you. Certain things you
can do automatically in .Net would require a lot of programming in
Access, and vice versa.

Access is billed as RAD, but, in my experience I think of it more as a 4GL (Like Oracle Forms)
in that its strongly cantered around the database?

I think in .NET you would have to use one-time wizards to do similar things.

.Net has a MUCH better development methodology, and vastly superior
language features, to VBA. (Note that VB.NET, or a subset, may become
the scripting language for Access in the near future. If so,
development opportunities in Access will dramatically open). I don't know VB6, coming to C# from C/C++.
Learning VB6 feels like a step backward!
As far as free solutions, you will notice tons of code fragments, but
very few complete components (add-ins, etc). This is because Access
does not lend itself to component development. What I am supposed to do is a CONTACT MANAGEMENT solution.
It should be quite a common thing, and I think it would be nice for me
to start from a well-written one (We certainly will need some customization
anyway)

well-formed solutions to a problem class that you can simply plug in
and use. What you will find is a lot of work-arounds to limitations in
Access. When you see all the smart people spending so much time fixing

I imagined that if I bump into something difficult to do with Access,
I could write Windows Forms code in .NET talking to JET with Classic ADO.
How difficult would that be to integrate? Any locking issues?

I think the core should be in Access to make it easy for other people to
maintain.
I think this kind of app is perhaps a good match for Access, and it would be
nice for me to spend one week with Access, rather than one more week with
..NET.
Thanks everybody
Olav

Nov 13 '05 #5

P: n/a
"Ken Ismert" <ki*****@texassystems.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
Olav,

The contrarian view:

If you have sufficient expertise in programming databases with .Net,
Access will likely not be a step forward for you. Certain things you
can do automatically in .Net would require a lot of programming in
Access, and vice versa.

Access is billed as RAD, but, in my experience I think of it more as a 4GL (Like Oracle Forms)
in that its strongly cantered around the database?

I think in .NET you would have to use one-time wizards to do similar things.

.Net has a MUCH better development methodology, and vastly superior
language features, to VBA. (Note that VB.NET, or a subset, may become
the scripting language for Access in the near future. If so,
development opportunities in Access will dramatically open). I don't know VB6, coming to C# from C/C++.
Learning VB6 feels like a step backward!
As far as free solutions, you will notice tons of code fragments, but
very few complete components (add-ins, etc). This is because Access
does not lend itself to component development. What I am supposed to do is a CONTACT MANAGEMENT solution.
It should be quite a common thing, and I think it would be nice for me
to start from a well-written one (We certainly will need some customization
anyway)

well-formed solutions to a problem class that you can simply plug in
and use. What you will find is a lot of work-arounds to limitations in
Access. When you see all the smart people spending so much time fixing

I imagined that if I bump into something difficult to do with Access,
I could write Windows Forms code in .NET talking to JET with Classic ADO.
How difficult would that be to integrate? Any locking issues?

I think the core should be in Access to make it easy for other people to
maintain.
I think this kind of app is perhaps a good match for Access, and it would be
nice for me to spend one week with Access, rather than one more week with
..NET.
Thanks everybody
Olav


Nov 13 '05 #6

P: n/a
On Thu, 13 Jan 2005 14:55:48 +0100, "Olav.NET" <Ol******@hotmail.com>
wrote:
<snip>
I don't know VB6, coming to C# from C/C++.
Learning VB6 feels like a step backward!

Well, C was a step backward from other Algol-inspired system languages
around at the time, (other languages had strings for example, the lack
of them in C has caused viruses and memory errors ever since) and C++
was in some ways a step back from C (all the overloading crap). Don't
know much about C#.
David
Nov 13 '05 #7

P: n/a

Albert,
What exactly do you mean by professional results?
I mean, making hard-to-break, consistent applications in a reasonable
amount of time. Prototyping the app is always fast in Access. Getting
Access to work reliably in a production environment is time-consuming
and difficult.
I am going on the record and telling you it is the reverse!!! Results andlack of consistency is MUCH worse in VB.net then it is in ms-access.


I think we need to distinguish between practitioner and tool. You are
an outlier - someone who has learned to leverage Access far beyond
what the average Access developer can manage. And, as the Access
developer community can attest, the average Access developer can
produce incredible messes.

You get outstanding results in Access, but I put forward that, with
similar effort, you or a developer with similar talents could get
outstanding results in .NET, too. The best practitioner in one product
will always beat the average practitioner in another.

The comparison I'm trying to make is between the relative power of
the two development systems. .NET is a much more powerful set of
language platforms than the VB6 style macros supported by Access. I
don't think there is any serious argument there. Even MS has moved
from VBA to .NET in their latest Office developer suite.

More power equals more time to learn and more discipline in use. But, I
contend an outlier in .NET who truly understands the tool and the
problem to be solved will be more productive in .NET than Access. Once
one learns to leverage that power, the results will speak for
themselves.

Because my intent is not to get into a detailed debate on the merits of
the two approaches, I will end by restating my position that Access has
a lot of shortcomings, and these inevitably cause loss of productivity.
Whether MS will successfully address these problems in upcoming
releases remains to be seen. Hopefully they will. What should be clear
to all is that .NET is the platform of the future for MS, and not just
for marketing reasons. It has genuine technical merit. That advantage
will translate to a better, more productive platform for doing the
things data applications will need to do in the coming decade.

-Ken

Nov 13 '05 #8

P: n/a
>What I am supposed to do is a CONTACT MANAGEMENT solution.
It should be quite a common thing, and I think it would be nice for me
to start from a well-written one (We certainly will need some customizationanyway)
Google on 'Access Contact Management' and you'll probably find some
samples. You may even find one that's workable for you.
I imagined that if I bump into something difficult to do with Access,
I could write Windows Forms code in .NET talking to JET with Classic ADO.How difficult would that be to integrate? Any locking issues?


You certainly can. Depending on the Recordset Type and Record Locks
properties in an Access form, there may be locking issues. However,
these are fairly easy to work around.

If you get stuck, you'll find that people on this forum and others are
good about responding to specific questions. Good luck with your app.
-Ken

Nov 13 '05 #9

P: n/a
"Ken Ismert" <ki*****@texassystems.com> wrote in
news:11*********************@c13g2000cwb.googlegro ups.com:
What exactly do you mean by professional results?
I mean, making hard-to-break, consistent applications in a
reasonable amount of time. Prototyping the app is always fast in
Access. Getting Access to work reliably in a production
environment is time-consuming and difficult.


Says who? Maybe you're simply incompetent?
I am going on the record and telling you it is the reverse!!!
Results

and
lack of consistency is MUCH worse in VB.net then it is in
ms-access.


I think we need to distinguish between practitioner and tool. You
are an outlier - someone who has learned to leverage Access far
beyond what the average Access developer can manage. And, as the
Access developer community can attest, the average Access
developer can produce incredible messes.


I've seen just as many horrid VB apps as I've see horrid Access
apps. The difference between two is that companies have actually
been able to get useful work done with the horrid Access apps.

The shocking thing to me about Access is exactly how forgiving of
pilot error it happens to be. Lots of amateurs are able to hack
something together that actually makes them more productive. Now, as
a professional, I look at these apps and see all sorts of horrid
problems (schema mis-design, UI problems, data consistency issues,
etc.), but the people that use them still find that they get things
done with them.

The same level of (in)competence with VB or VB.NET gets you exactly
nowhere, and I've seen plenty of 90%-complete data-oriented VB
projects that were abandoned because THEY NEVER WORKED AT ALL.
You get outstanding results in Access, but I put forward that,
with similar effort, you or a developer with similar talents could
get outstanding results in .NET, too. The best practitioner in one
product will always beat the average practitioner in another.
In data-oriented apps, Access in the hands of an experienced
developer will always be faster than any alternative development
platform.
The comparison I'm trying to make is between the relative power of
the two development systems. .NET is a much more powerful set of
language platforms than the VB6 style macros supported by Access.
Macros? What are you talking about?

If all you know about Access is building macros, then YOU DON'T KNOW
JACKSH*T ABOUT ACCESS.
I don't think there is any serious argument there. Even MS has
moved from VBA to .NET in their latest Office developer suite.
And we'll see how they manage the conversion in Access. My bet is
that the version of VB.NET embedded in Access.NET (when it
eventually comes out) will have a much richer data-oriented event
model than plain-jane VB.NET.
More power equals more time to learn and more discipline in use.
But, I contend an outlier in .NET who truly understands the tool
and the problem to be solved will be more productive in .NET than
Access. Once one learns to leverage that power, the results will
speak for themselves.
I think you're wrong, unless the .NET developer has already built a
huge suite of data-oriented components to plug into their
applications. If you factor the time to produce those components
into the applications it's used in, then I don't think that
developer would any longer have any advantage over the experienced
Access developer (if there was even any advantage in the first
place!).
Because my intent is not to get into a detailed debate on the
merits of the two approaches, . . .
Good thing, since your mention of macros shows that you're
completely lacking in the competence needed to discuss Access at
all. . . .
. . . I will end by restating my position
that Access has a lot of shortcomings, and these inevitably cause
loss of productivity. . . .
You are ignoring the other half of the ROI equation, the areas in
which Access improves productivity. If those outweigh whatever
shortcomings Access has (and experienced Access developers know them
far better than people who don't use Access on a daily basis), then
the net for Access is a GAIN in productivity.
. . . Whether MS will successfully address these
problems in upcoming releases remains to be seen. Hopefully they
will. . . .
The "shortcomings" you've cited sound more like shortcomings in
*you* -- you don't seem to have much experience with Access if you
can't properly navigate the data-oriented events of forms, and are
still using macros for anything at all (other than AutoExec).
. . . What should be clear to all is that .NET is the platform of
the future for MS, . . .
Yadda, yadda, yadda -- in 1999, ADO was the data access method of
choice, and now it's completely abandoned, in favor of a completely
different data access method that has a suspiciously similar name.
. . . and not just for marketing reasons. It has
genuine technical merit. . . .
For general development, OF COURSE.
. . . That advantage will translate to a
better, more productive platform for doing the things data
applications will need to do in the coming decade.


I think you're spouting complete rubbish based on a lack of any real
experience using Access on a regular basis.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #10

P: n/a
"Olav.NET" <Ol******@hotmail.com> wrote in
news:41*********************@news.skynet.be:
I imagined that if I bump into something difficult to do with
Access, I could write Windows Forms code in .NET talking to JET
with Classic ADO.


What the f*ck?

You obviously don't have a clue what you're talking about.

Are you talking about writing an Access application or using a Jet
database to store your data?

If the former, you can't integrate a Windows Form into your
application (though you could create one that could manipulate Jet
data).

If the latter, Access has nothing to do with the question.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #11

P: n/a
"Olav.NET" <Ol******@hotmail.com> wrote in
news:41*********************@news.skynet.be:
What I am supposed to do is a CONTACT MANAGEMENT solution.
It should be quite a common thing, and I think it would be nice
for me to start from a well-written one (We certainly will need
some customization anyway)


Contact management is one of the most complex applications you will
ever encounter. Just defining your basic entities is a challenge.

I've spent my entire Access development career (going back to 1996)
struggling with the question of how to design contact management
systems. I still don't know the best answers for data schema and UI.

I can guarantee you that I've never seen a commercial product that
comes even close to getting it right.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #12

P: n/a
rkc
Ken Ismert wrote:
What should be clear
to all is that .NET is the platform of the future for MS, and not just
for marketing reasons. It has genuine technical merit. That advantage
will translate to a better, more productive platform for doing the
things data applications will need to do in the coming decade.


Like what?
Nov 13 '05 #13

P: n/a
rkc,

Microsoft operating systems are built around object methodologies. For
Win95 thru XP, that was COM. For the Longhorn OS, it is now .NET. The
whole operating system is being built on this new object system. All
major new components, from ASP.NET web servers to SQL Server 2005 are
built from the ground up with it, or are heavily optimized to work with
it. .NET isn't some transient marketing trend. Microsoft has bet the
farm on it.

This change is in response partly to technical shortcomings of COM,
and, more importantly, to the sea change of computing that is partly
driven by, and partly engulfing, Microsoft.

The trend is away from the desktop, away from client-server (Access
roots) and towards the web and web applications. Microsoft's
cutting-edge technologies are all web-centric (ASP.NET, InfoPath,
SharePoint).

The question for the Access programmer, particularly the professional
ones, is how can I grow and continue to make money in this new
environment? Especially in light of Access' historical lack of any
meaningful web support, how do you compete in an increasingly
loosely-connected, distributed, web-dominated market?

The niche Access has now is secure - its still the best at what it
does. But, I fear that niche is becoming increasingly small. Large
corporations are increasingly disaffected with Access as an ad-hoc
solution for their smaller departments. Integration and centralized
data, even at the expense of function, is the new trend.

Microsoft may well pull Access out of the fire, and restore the ability
for professionals to make money with it. But it may not. What is
certain is that this group will see more and more Olavs, with .NET
jobs, asking questions about how they can best work with this legacy
'Access' thing.

And maybe that's a trend we, as Access users, should take notice of.
-Ken

Nov 13 '05 #14

P: n/a
>... My bet is that the version of VB.NET embedded in
Access.NET (when it eventually comes out) ...

Maybe you should start learning .NET?

-Ken

Nov 13 '05 #15

P: n/a
You might want to check out Matthew Hood's post on Jan 6 in
microsoft.public.access.formscoding, among others.

Apparently (if I understood it correctly) using Windows .NET forms inside
Access is more possible than I would have imagined...
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...
"Olav.NET" <Ol******@hotmail.com> wrote in
news:41*********************@news.skynet.be:
I imagined that if I bump into something difficult to do with
Access, I could write Windows Forms code in .NET talking to JET
with Classic ADO.


What the f*ck?

You obviously don't have a clue what you're talking about.

Are you talking about writing an Access application or using a Jet
database to store your data?

If the former, you can't integrate a Windows Form into your
application (though you could create one that could manipulate Jet
data).

If the latter, Access has nothing to do with the question.

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

Nov 13 '05 #16

P: n/a
rkc
Ken Ismert wrote:
rkc, The trend is away from the desktop, away from client-server (Access
roots) and towards the web and web applications. Microsoft's
cutting-edge technologies are all web-centric (ASP.NET, InfoPath,
SharePoint).

The question for the Access programmer, particularly the professional
ones, is how can I grow and continue to make money in this new
environment? Especially in light of Access' historical lack of any
meaningful web support, how do you compete in an increasingly
loosely-connected, distributed, web-dominated market?


I have to agree with at least one point you're making. Access is
not now and probably never will be a tool for creating web delivered
browser based applications. ADP's or DAP's or whatever the hell they
were called seem by most accounts to have been a dismal failure.
Nov 13 '05 #17

P: n/a
"Ken Ismert" <ki*****@texassystems.com> wrote in
news:11**********************@z14g2000cwz.googlegr oups.com:
... My bet is that the version of VB.NET embedded in
Access.NET (when it eventually comes out) ...


Maybe you should start learning .NET?


On the same theory that everyone said I should learn ADO when A2K
was released?

I was smart enough to see through that, and I'll learn .NET when it
has a benefit to my clients to do so, and not one minute sooner.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #18

P: n/a
I been out for a day here.

And, Ken...yes...it is not productive for me and you big long drawn out
fight on this issue!!

(so, I going to keep this short..as we both are likely busy people!!!).

First, thank you for your comments

And, right off the bat, I want to say I generally agree with your comments.

Without question, we as the developer community do have to make the leap to
OO as a general tool and approach to software development. It is coming, and
is a un-stoppable force....

I can remember in the early 90's how us developers had to make the jump from
procedural development to event driven..and many did not care to make this
jump!

And, for a lot of the ms-access developers that use class objects, they will
find the jump to .net quite easy. So, as in .net you create a new instance
of a form (as opposed to opening one in vb6, or ms-access). However, this
concept feels very natural to me, since I always use class objects in
ms-access. So, some concepts, and OO training has occurred to ms-access
developers (I am only mention this fact for all the people reading this post
that the leap to OO is not hard!!).

And, yes...I can imagine that over time, that I will built up a nice set of
classes for forms to consume in .net that gives me a good leg up in
development.

As more time passes, each of the things I need to solve in .net will get
solved. The advantage of .net is the OO nature allows me to solve a problem,
and then UTILIZE that solution in NEW projects (this is in fact where .net
is better then the old VB6 model). If one views software as a tool building
exercise, then OO does help a lot. I have always taken a toolbox approach to
software development.

So, for example, I miss the where clause of a form in .net (one of my
favorite ms-access features). I going to simply build a nice class that does
this for me in .net, and then from that time period forward, all my forms
will have a "where" clause! (ok..method!!) So, yes..I do believe with some
efforts, and building up my library of tools,.net will give me good
productivity.

However, I don't ever see it surpassing or equaling that of ms-access in
terms of making curd forms......at least right now I can't see this!!
Ms-access is just too good at this task right now!!

It will interesting to see what I think from a year from now. Sure. And, in
fact, I do think I can get better results in .net, but the effort and time
also is greater, and where I come from this is all about turning code into
dollars!!.

net is not a fad, and is very important change for how software is going to
be developed. The .net offers a unified development system to solve most of
the challenges that we have in todays market place. Stuff like being able to
write .net code for sql-server (sql 2005 edition) means I can write and use
my favorite .net language and have that code run on the sql server! In fact,
this feature ALONE has sold me on .net. And, of course the fact the whole
development platform can even be used to write software for a pda is an
another incredible issue to me. And, writing stuff for the web.

The fact remains that .net encompasses 4 distinct areas of software
development that is important for business (web, desktop, pda, and sql
server). People talk about all kinds of reasons to use .net..but for me..it
is the WIDE cut of the 4 basic areas that developers need. The investment in
the technology results in one be able to work in 4 major areas.

I actually believe that in the marketplace, .net is, and will win over other
vendors solutions, and the reasons why is how well it works in all 4 areas
of development.

..net might be good, but why it will win is the wide path it makes is the
real key here!!

I don't think I will ever be more produtive in .net, then that of ms-access!

Ms-access remains a hot knife through butter...and I don't know of a sharper
knife!

Once again..thanks for your comments...

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

P: n/a
Albert,
...However, this concept feels very natural to me,
since I always use class objects in ms-access...
Working with classes and objects is a great way to prepare for working
with .NET. Moreover, relational theory and normalization are timeless
concepts - expertise developed in these core areas will carry over
into any programming environment. An Access developer with these
competencies has a good amount of future-proofing built-in already.

Good database application design can be learned in any platform. This
is an area where a seasoned Access developer will have an edge over an
otherwise competent .NET coder who is inexperienced at building data
apps. My bet, for a .NET project, would be on the Access developer,
because they have in their head a good idea of what they are shooting
for.
The fact remains that .net encompasses 4 distinct
areas of software development that is important
for business (web, desktop, pda, and sql server)...
A good summary of the breadth of the .NET initiative.
...and where I come from this is all about turning
code into dollars!!...


Precisely.

My closing thought is an Access developer should not only grow down,
into the specific details of how to make things work in Access, but
also up, taking the time to grasp the broader issues and general
principles. When you realize that you are building data applications,
not Access programs, you will start to use the tools at your disposal
in a more generic, abstract way. This will help you make the most out
of what you have now, and make you more nimble when the time comes to
change.

-Ken

PS. Want to develop in .NET, but are put off by the price of Visual
Studio? Download Micosoft's .NET framework (its free) and use a free
IDE:
http://sharpdevelop.net/OpenSource/SD/Default.aspx

Nov 13 '05 #20

P: n/a

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...
"Olav.NET" <Ol******@hotmail.com> wrote in
news:41*********************@news.skynet.be:
I imagined that if I bump into something difficult to do with
Access, I could write Windows Forms code in .NET talking to JET
with Classic ADO.


What the f*ck?

If two applications have UI controls bound to the same database,
its already pretty much one application.

Its just a question of how well you can do it, and for some tasks it would
have to
be closer integrations than others.

(My app doesnt't need to have a "professional" look and feel)

Olav
Nov 13 '05 #21

This discussion thread is closed

Replies have been disabled for this discussion.