access vs visual basic 6.0 vs visual basic.net

[Brian]

what is the difference between access and visual basic
6.0? And then the difference between vbasic 6.0 and
visual basic.net?
I'm looking for a programming language for a few, small
tasks that will require a good deal of logrithmic
calculating.
thanks

 

[david epsom dot com dot au]

Access 2000,2002, and 2003 use a version of VB that
is the same as the version of VB that comes with VB6,
but won't optimise as well without VB6.

Access also comes with a Forms engine and a Report
engine that do Forms and Reports.

VB6 also comes with a Forms engine (and depending on
the version, a Reports engine) that are different
from what you get with Access, and will optimise
the code better than Access will.

VB.Net is a different language, with some similarities
(Like Fortran was similar to Basic). VB.Net uses
Windows Forms (like Excel and Word), or HTML and
a web browser. You can also get a report engine:
for example you could use SQL Server report services.

If you are thinking of doing Internet stuff, vb.net
is the clear leader: Access is best for small scale
RAD database stuff: Word/Excel/Outlook are best
for Word/Excel/Outlook data: VBscript for small
utilities: VB6 for sites that don't support the .net
framework, or stuff already in VB, or written by
somebody who already uses VB.

I can't compare code optimisation in .Net with
vb6: I don't know how fast they run comparatively.


(david)

 

[onedaywhen]

VB6 also comes with a Forms engine (and depending on
the version, a Reports engine) that are different
from what you get with Access, and will optimise
the code better than Access will.

VB.Net is a different language, with some similarities
(Like Fortran was similar to Basic). VB.Net uses
Windows Forms (like Excel and Word)

Excel and Word come with UserForms (MSForms class) and their own
flavor of ActiveX controls. They are closest to the VB6 form; more
limited but the controls are largely similar. They are most definitely
not .NET Windows Forms.

My personal experience is MS Access forms, and most notably their
ActiveX controls, behave completely differently to userforms and VB6
forms, so much so I recommend not using them.

--

 

[onedaywhen]

My personal experience is MS Access forms,
and most notably their ActiveX controls,
behave completely differently to userforms
and VB6 forms, so much so I recommend not
using them.

That was ambiguous! I meant I recommend not using MS Access forms.

--

 

[Albert D. Kallal]

I will agree that the ms-access forms are far more complex to learn and use
then are the simple VB6 forms.

However, you have to remember that ms-access forms have nearly double the
events, and double the properties as compared to a simple VB6 form.

So, if you take the time to learn ms-access forms you then can use a complex
object to accomplish MUCH MORE then what you can with a VB6 form in the SAME
amount of time. In fact, you will as a general rule find about 3 times the
production of applications in access as compared to VB6 when dealing with
data
centric applications. That means a $8000 project in ms-access will set you
back $25,000 grand in VB6.

Yes...but as result..you get incredible increased productivity. So, for
example
our combo box is different ..but has FAR more flexible then the lame VB6
combo box. Our combo box has standard events on on-got focus..but also
things like on-enter. In addition to on-change we get after update, and even
more useful events like "on not in list" (which thus allows us to prompt
the user to add new items to a combo). Further, the combo box allows
multiple columns to be displayed (something again missing in the VB
control).
So, yes..very differnt..and again MUCH MORE properties and MUCH more events
for the control available saves TONS of code.

Take a look at the following screen shots done in ms-access..and then try to
re-produce the same functionality in VB6...my estimates of 1/3 the time are
actually conservative.

http://www.attcanada.net/~kallal.msn/Articles/Grid.htm

And, the code behind those buttons to launch a detail form to the selected
record takes ONE line of code in ms-access.

Just because those forms are different...don't mean they are bad. Once
mastered
those access forms run ABSOLUTE circle around VB forms when editing data.
Even simple things like the fact that ms-access forms have both a on-load
event, and also a on-open event

What is nice..is the on-open event has a cancel option..and thus can prevent
the loading the form. Hence, the on-open event can do this like check for no
data...or even try to grab a record lock...is not successful then we can
cancel the form load. Once the form loads then the on-load event runs (this
is where we can put all the setup code for the form). In VB you have none of
this division...and trying to cancel a form load with code in the actual
form is pain (and, all the conditions and setup code belongs with the form
anyway).

I could write for pages and pages. And...lets not even get into reports.....

I would not expect one to write a pac-man game in ms-access (but most
certainly yes in VB6). However, the reverse is also true...you write a data
centric application ms-access will run circles around VB6 forms...

 

[onedaywhen]

if you take the time to learn ms-access forms you

then can use a complex object to accomplish MUCH
MORE then what you can with a VB6 form in the SAME
amount of time. In fact, you will as a general rule
find about 3 times the production of applications
in access as compared to VB6 when dealing with
data centric applications. That means a $8000
project in ms-access will set you back $25,000
grand in VB6.

I am a developer not a client hiring a developer. What interests me is
re-use of code: re-use when it comes to release 2 of the current app
and re-use when it comes to work on the next project (i.e.
transferable skills). Learn VB6 forms and you are most of the way to
learning e.g. .NET Windows Forms. Invest my time learn quirky MS
Access forms and those skills would not be transferable outside MS
Access apps. Once I'd spent time learning them, that 2/3 saving in the
short term would cost me in the long run. I've heard say it takes a
good part of a year to 'un-learn' MS Access. I've built a few data
access (small 'a') tiers in my time so I've got some transferable
skills (the MS Access apps I've seen don't seem to have a data access
layers). This is how I can be competitive in terms of 'time is money'.

Your notes that accompany your screen shots confirm why I will never
use MS Access forms. Allow me a few quotes:

"you can shove sql right into the listbox and not even
have to build a connection object. (gosh...we are just
so spoiled in ms-access)"

But my connection and recordset objects have certain crucial
properties (client side cursors, disconnected results sets, batch
optimistic locking, asynchronous connection, etc) why is the form
hiding all this from me? And my sql is in parameterized stored
procedures i.e. sql is on the server side not in client code.

"similar to control arrays, and cloned controls in VB,
but is much better since the controls ARE DATA
BOUND for you! Once you stuff the sql into the
control, no additional coding is required for editing of
data!"

I need closer control over the data, I don't want bound controls.

"mind you, I only have 5 users ... on a small network
with such small tables"
Hmmm.

And...lets not even get into reports

Shame, because we would've probably started agreeing. The MS Access
reports engine is quite nice, the VB6 one is very basic.

--

 

[Albert D. Kallal]

Learn VB6 forms and you are most of the way to
learning e.g. .NET Windows Forms. Invest my time learn quirky MS
Access forms and those skills would not be transferable outside MS
Access apps.

Hum, that is matter of opinion. I don't think the jump from VB forms to .net
or from ms-access forms to .net is going be much different at all here. Any
competent developer will make this leap. The idea you are proposing here is
that ms-access forms teach some bad habits...or hold back the developer some
how. The worst business applications I seen are written in VB6. So, it is
very possible that since VB6 is so un-structured when it comes to data
forms..that you actually learn worse habits in VB6 then you do in ms-access
(just like a language that has no data typing vs one that does). At least
the forms data model and events is consistent from one application to the
next in access, I can't say that for VB6.

As for future skills?...Hum...at least we got a nice new version of
ms-access in the works...can't say that for VB6...can we?

I've heard say it takes a
good part of a year to 'un-learn' MS Access.

Well..again, that is kind of here say. The programming language in ms-access
is the same as VB6 anyway (sans the forms model). So, really, we are talking
about a VB development system with a different forms object. Not really a
big deal here except for the labour savings you get when working with data.
The IDE between VB6 and access are quite similar. Of course..since forms are
the heart an soul of an application..I would be silly not say there is a big
difference..but the language is the same in both cases.

I've built a few data
access (small 'a') tiers in my time so I've got some transferable
skills (the MS Access apps I've seen don't seem to have a data access
layers). This is how I can be competitive in terms of 'time is money'.

Most business applications are two tried when you talking about VB6, or
ms-access to sql server. If you do need, or plan to build a 3 tried
applications, then without question ms-access is likely NOT the right tool.
However, you *can* consume .net web services in ms-access now with the soap
tools add in kit for ms-access. So, that would give one an ability to
develop 3 tried systems with access. However, for a very LARGE slice of
business applications market...a two tried design is fine. I have no problem
with the issues of using the right tool for the right application.
Ms-access makes a great client to sql server, and thus is good choice in a
two tried environment. For 3 tried...hum...likely not the best choice.

But my connection and recordset objects have certain crucial
properties (client side cursors, disconnected results sets, batch
optimistic locking, asynchronous connection, etc) why is the form
hiding all this from me?

Again, if you need a disconnected recordset, or need to code that
stuff..there is nothing stopping you from doing that in ms-access. The
problem is 9 out 10 times you don't need to do that. You have the full ADO
object set available in ms-access. You can code your heart out in that
regards if you want...the real problem is when you DON'T need to..you *have*
to in VB6.

And my sql is in parameterized stored
procedures i.e. sql is on the server side not in client code.

Well, if we are talking sql server here (are we???). You are well aware that
a access ADP project is 100% native sql, NO jet engine, and no local tables.
No local engine even exists to process the sql (it all 100% sql server
native application). So, any stored query means that all sql processing is
done on the server. So, lets not jump to quick as to how ms-access can , or
can not work with sql server. ADP projects have been available in ms-access
for the last 3 versions of office (and, on the office cd is the MSDE desktop
edition of sql server. So, for 3 versions of access we have been able to
create native sql applications). You HAVE to use a server engine when you
use access ADP projects. However, this really comes down to how the
developer is going manage where, and how the sql is used. This is a
developer decision..not one of ms-access anyway. However, if we are talking
a NON server based application..and JET? Well, then ms-access is far
better..since we have a nice query builder and collection of queries. This
more often then not makes the developer put the sql out side of the
code..and NOT use in-line sql. (so, I would again say as a general rule..vb
guys use more in-line sql then does access folk..since we have a wonderful
"querydefs" collection that we can use (and,that querydefs collection
supports the use of parameters).

I should also say that if you user count is only going to be 50 to 150
users..then I never seen ANY difference in sql server performance with odbc
as compared to a OLEDB connection that ADP access projects provide. This
native connection business about oleDB and odbc is much a urban myth. For
most applications..you will not see ONE BIT of performance difference
between the two approaches to sql server (ie: native ADP access projects vs.
ODBC to sql server). I don't know why, or how it is that people often think
that ms-access does not work, or somehow is not able to work with sql
server. Access is a fine client..and every bit as good (in fact many ways
better) then VB6. Again..we talking about that 90%+ applications of being
two tried here.

If you do need a middle layer..then I do concede that the debate does widen.
(you can consume .net services in ms-access...but you can't create them!).
So, for 3 tried...likely ms-access is not the best choice (but there is
still some room for debate here!).

I need closer control over the data, I don't want bound controls.

Yes, and in most cases you do need more control. The first problem is that
the VB controls are very bad in working with data. If you had the events an
extra methods and properties that ms-access provides then in a large portion
of those cases you could get away using bound controls. Bound controls/forms
are not so bad when those forms have a whole bunch of extra methods to deal
with data editing. For example, just for deletion..we have the following
events:

On Delete
Before Del Confirm
After Del confirm

Once again, without these extra events to work with when a deletion occurs,
then you need to write code. To have code run, or occur on one of the above
given events..you are forced to write REAMS of code for the shortcomings in
VB6. VB6 is just not designed from the group up to do data editing. So,
sure..you do get more control in VB...but so does assembler give you more
control. I am not sure that being forced to write a bunch of extra code due
to the objects lack of design is a good thing. To get more control you have
to write a ton of code. And, of course this rapidly forces you to go the
un-bound way. Like I say..bound forms without extra events and methods deal
with bound data is a nightmare.

Since VB6 does not have bound data forms..then you have little choice in
this matter. And, thus you get that large increase in application cost I
talked about. I will be the FIRST to admit that many a performance
problems occur when bound objects are miss-used. However, miss use of bound
objects should not be an argument to kill the use of them!

Without question there are times when bound controls are bad. However, if
those bound controls have a ton of extra methods and properties..then THEY
ARE just fine to use. And, there nothing stopping one from using standard
active x controls like listview or a treeview in ms-access (but..then you
are forced to write code to fill those things).

This really comes down to the right horse for the right course. Products
like FoxPro, Dbase, ms-access etc took the market by storm many years ago
and catapulted the desktop pc into being a useful data management system.
These data systems now work very well with server based engines also.

I not going to write a game in Auto Cad, nor would I try and use VB6 in
place of auto - cad. The same goes for these database projects in the market
place. They simply would not exist if products like VB6 could do a better
job. Why would anyone use a database product over VB6 if vb6 was better?
This makes no sense at all, none more so to throw out auto-cad and try and
use VB6 in its place.

When projects need certain features (like highly customized UI), or wide
product distribution, or a larger development team using a multi-tiered
approach...then VB6 starts to become a better development tool....and
rightfully so. I would not argue differencing on this issue.

This all about the right tool for the right job!

When it comes to a data centric project......the winning bets most of the
time are on the horse called ms-access.

 

[onedaywhen]

...

Thanks for your views, sincerely appreciated. I'll just post some
corrections/addendums:

The idea you are proposing here is
that ms-access forms teach some bad habits

I suspect it may but would not air that view because, as I've made
clear, my experience of MS Access forms is too limited. Rather, my
'idea' is that MS Access forms are unique and most unlike Excel/Word
userforms, VB6 forms and Windows forms. Just consider the concept of
'sub forms' - MS Access only!

At least the forms data model and events
is consistent from one application to the
next in access

That is a good point I hadn't considered. That said, if a MS Access
user is accustomed to reusing the same model they may find it hard
when it's time to move to another application.

at least we got a nice new version of
ms-access in the works...can't say that
for VB6...can we?

I use VB6 as an example because it's arguably the closest to MS
Access. Even so the forms engines are very different, and that's my
point in a nutshell. I could counter that the next 'VB6' is called
Whidbey and the next version of MS Access will be Access2000 with a
few more bolted-on tools and without the developer's version having
the redistributable runtime you will have lost more than you will have
gained, but that would be too off thread.

Most business applications are two (tiered)
when you talking about VB6... we talking
about that 90%+ applications of being two
(tiered) here

That's not me talking because in my experience that is not the case.
[BTW your word processor seems to be auto-replacing the word 'tiered'
with 'tried'.]

If you do need... to build a 3 (tiered)
applications, then without question
ms-access is likely NOT the right tool.

Agreed. And (at least) three tiered is my requirements.

you *can* consume .net web services in
ms-access now with the soap tools add-in

One of the aforementioned bolted-on tools. But I was thinking here in
terms of desktop applications with a data access layer.

if you need a disconnected recordset...
in ms-access... you DON'T need to..you
*have* to in VB6.

Incorrect. ADO, whether in MS Access or VB6, allows you to maintain
the recordset object's ActiveConnection property e.g. issuing the
Update method sends any changes to the data source, meaning a bound
recordset. And in VB6 you can associate a connected recordset with an
ActiveX control i.e. you can have bound controls too.

a access ADP project is 100% native (SQL
Server) ... Access is a fine client

Why then is MS Access not the number one choice for SQL Server based
apps, I wonder?

Bound controls/forms are not so bad when
those forms have a whole bunch of extra
methods to deal with data editing. For
example, just for deletion..we have the
following events:
On Delete
Before Del Confirm
After Del confirm

Another good point. I guess I'm not afraid of investing time in
writing some classes to extend the functionality of intrinsic (and
other) ActiveX controls to get the functionality I require. Even
writing one's own ocx is a viable option if it's going to get some
re-use. Ever find in MS Access you are putting the same code in the
same event handlers and have a large number of controls you never use?

VB6 does not have bound data forms

Incorrect. The Data Environment can be bound ASAIK and other controls
can be bound using either a ADODB Data Control or a connected
recordset object.

there nothing stopping one from using
standard active x controls like listview

I take up your challenge! I'll try to add a listbox to a form,
populate it manually with some items and show a message using the
selected values. Maybe the following description of my experience will
demonstrate what I've been trying to say (and/or make me look a fool
but never mind!)

I open a .mdb file in MS Access 2003. I need a form so I choose Insert
Form, choose Design View from the unasked for wizard, close the form
expecting a save as dialog but the form has disappeared. Start again,
this time explicitly save the form by choosing Save As (I must specify
to save as a form?! Mind boggle at what else it could be!). Form is
now closed and saved. Choose View, Code: MS Access goes GPF, I have a
C++ debugger which tells me, 'This application has requested the
Runtime to terminate it in an unusual way'. Restart MS Access, this
time I can't view the code because I don't have exclusive access to
the database, an uncleared lock? Restart the machine, apparent lock
has cleared but View, Code goes GPF again. Hmm. Must find a way of
tricking MS Access into viewing the code module. After several GPFs I
finally get the VB editor to open. Phew! Choose List0 from the
objects, look at the events: seems to be the normal quota, wonder
where are all the extra events I've heard about? In the Form_Load
event, add some items e.g.

With List0
.AddItem "One"
.AddItem "Day"
.AddItem "When"
End With

Want to test the form, press the 'VCR Play' button, doesn't run the
form but brings up a blank list of macros. OK, so add a standard
module, add a public sub named 'Test' to show the form from here. Try
Form1 but haven't got that object, notice in the VBE its called
Form_Form1 (why?!), OK that's a public object but it hasn't got a Show
method, look for something else (notice it has many properties named
as if they were events e.g. AfterUpdate, BeforeInsert, etc - weird!),
try to load it:

Load Form_Form1

but get error 'Can't Load or Unload this object'. Visible property is
a possible candidate so try,

Private frm1 As Form_Form1
...
Set frm1 = New Form_Form1
frm1.Visible = True

At first think it hasn't worked but the form is shown behind the VBE
window (!!). Success! But there is something that looks like the ADOBC
Data Control at the bottom of the form, that will have to go. Go to
the form designer again (I'll spare you the numerous subsequent GPFs),
look at the form properties, can't see anything, look again and
realize I must change drop down to 'Form' (why?!), this is revealing:
I apparently have an unasked for recordset of type 'Dynaset' (wonder
whether this is MS-Access-speak for 'keyset cursor' or 'dynamic
cursor'?), change navigation buttons to No, run the form - success!
Now, add the functionality: back to the VBE, open a List0_Click event
handler, remember the ListBox has no List method, wonder how to get
current item, have got ListIndex to give me the index number but what
to do with it? Notice ItemsSelected but at run-time in the click event
the ItemsSelected.Count property is zero but didn't I just trigger
this event by selecting something? At this point I give up, concluding
that MS Access forms are a totally different experience, so doing even
a simple thing throws up all kinds of issues.

--

 

[david epsom dot com dot au]

re-use. Ever find in MS Access you are putting the same code in the

same event handlers and have a large number of controls you never use?

No. I don't. I bring the same discipline to VBA programming that
I bring to VB programming. Also :~) you would say that, being
a VB programmer :~) VB programmers have to PLAN to avoid repeated
code. Access programmers only have to LEARN to avoid repeated
code :~)

I'm not going to argue with your choice of tools, but I will
disagree with your idea about the danger of learning Access.

I've heard say it takes a good part of a year to 'un-learn'

I just don't agree with that. Not even close. The only possible
vaguely related idea that I can find, would be the point that
you don't actually have to be a programmer AT ALL to produce
useful business tools with Access, so you might find an Access
'developer' who has no programming skills AT ALL and takes a
good part of year to pick up ANY programming skills.

I take junior programmers from VB to Access, and from Access
to VB. There is a stack of additional stuff to learn going
from Access to VB: there is a small trivial amount to learn
going from VB to Access. Unlearning the small trivial amount
is trivial: unlearning the stack of additional stuff is
unnecessary.

BTW, On one workstation, the copy of VB5 crashes with a GPF every
time I exit, but we haven't been bothered enough by that to want
to do a new Win Install: there is two much stuff installed on that
PC anyway (VB4,VB5,VB6, Access 2,97,2000, etc etc) and we are
afraid re-installation would just re-create the same problem....

Apart from that, the actual experience (design tables, create
forms, write code, create reports) is not very different. That
is, less different than comparing the Excel programming experience
to Word, which I think are 'the same' on your scale.

(david)

"Albert D. Kallal" wrote ...

Thanks for your views, sincerely appreciated. I'll just post some
corrections/addendums:

The idea you are proposing here is
that ms-access forms teach some bad habits

I suspect it may but would not air that view because, as I've made
clear, my experience of MS Access forms is too limited. Rather, my
'idea' is that MS Access forms are unique and most unlike Excel/Word
userforms, VB6 forms and Windows forms. Just consider the concept of
'sub forms' - MS Access only!

At least the forms data model and events
is consistent from one application to the
next in access

That is a good point I hadn't considered. That said, if a MS Access
user is accustomed to reusing the same model they may find it hard
when it's time to move to another application.

at least we got a nice new version of
ms-access in the works...can't say that
for VB6...can we?

I use VB6 as an example because it's arguably the closest to MS
Access. Even so the forms engines are very different, and that's my
point in a nutshell. I could counter that the next 'VB6' is called
Whidbey and the next version of MS Access will be Access2000 with a
few more bolted-on tools and without the developer's version having
the redistributable runtime you will have lost more than you will have
gained, but that would be too off thread.

Most business applications are two (tiered)
when you talking about VB6... we talking
about that 90%+ applications of being two
(tiered) here

That's not me talking because in my experience that is not the case.
[BTW your word processor seems to be auto-replacing the word 'tiered'
with 'tried'.]

If you do need... to build a 3 (tiered)
applications, then without question
ms-access is likely NOT the right tool.

Agreed. And (at least) three tiered is my requirements.

you *can* consume .net web services in
ms-access now with the soap tools add-in

One of the aforementioned bolted-on tools. But I was thinking here in
terms of desktop applications with a data access layer.

if you need a disconnected recordset...
in ms-access... you DON'T need to..you
*have* to in VB6.

Incorrect. ADO, whether in MS Access or VB6, allows you to maintain
the recordset object's ActiveConnection property e.g. issuing the
Update method sends any changes to the data source, meaning a bound
recordset. And in VB6 you can associate a connected recordset with an
ActiveX control i.e. you can have bound controls too.

a access ADP project is 100% native (SQL
Server) ... Access is a fine client

Why then is MS Access not the number one choice for SQL Server based
apps, I wonder?

Bound controls/forms are not so bad when
those forms have a whole bunch of extra
methods to deal with data editing. For
example, just for deletion..we have the
following events:
On Delete
Before Del Confirm
After Del confirm

Another good point. I guess I'm not afraid of investing time in
writing some classes to extend the functionality of intrinsic (and
other) ActiveX controls to get the functionality I require. Even
writing one's own ocx is a viable option if it's going to get some
re-use. Ever find in MS Access you are putting the same code in the
same event handlers and have a large number of controls you never use?

VB6 does not have bound data forms

Incorrect. The Data Environment can be bound ASAIK and other controls
can be bound using either a ADODB Data Control or a connected
recordset object.

there nothing stopping one from using
standard active x controls like listview

I take up your challenge! I'll try to add a listbox to a form,
populate it manually with some items and show a message using the
selected values. Maybe the following description of my experience will
demonstrate what I've been trying to say (and/or make me look a fool
but never mind!)

I open a .mdb file in MS Access 2003. I need a form so I choose Insert
Form, choose Design View from the unasked for wizard, close the form
expecting a save as dialog but the form has disappeared. Start again,
this time explicitly save the form by choosing Save As (I must specify
to save as a form?! Mind boggle at what else it could be!). Form is
now closed and saved. Choose View, Code: MS Access goes GPF, I have a
C++ debugger which tells me, 'This application has requested the
Runtime to terminate it in an unusual way'. Restart MS Access, this
time I can't view the code because I don't have exclusive access to
the database, an uncleared lock? Restart the machine, apparent lock
has cleared but View, Code goes GPF again. Hmm. Must find a way of
tricking MS Access into viewing the code module. After several GPFs I
finally get the VB editor to open. Phew! Choose List0 from the
objects, look at the events: seems to be the normal quota, wonder
where are all the extra events I've heard about? In the Form_Load
event, add some items e.g.

With List0
.AddItem "One"
.AddItem "Day"
.AddItem "When"
End With

Want to test the form, press the 'VCR Play' button, doesn't run the
form but brings up a blank list of macros. OK, so add a standard
module, add a public sub named 'Test' to show the form from here. Try
Form1 but haven't got that object, notice in the VBE its called
Form_Form1 (why?!), OK that's a public object but it hasn't got a Show
method, look for something else (notice it has many properties named
as if they were events e.g. AfterUpdate, BeforeInsert, etc - weird!),
try to load it:

Load Form_Form1

but get error 'Can't Load or Unload this object'. Visible property is
a possible candidate so try,

Private frm1 As Form_Form1
...
Set frm1 = New Form_Form1
frm1.Visible = True

At first think it hasn't worked but the form is shown behind the VBE
window (!!). Success! But there is something that looks like the ADOBC
Data Control at the bottom of the form, that will have to go. Go to
the form designer again (I'll spare you the numerous subsequent GPFs),
look at the form properties, can't see anything, look again and
realize I must change drop down to 'Form' (why?!), this is revealing:
I apparently have an unasked for recordset of type 'Dynaset' (wonder
whether this is MS-Access-speak for 'keyset cursor' or 'dynamic
cursor'?), change navigation buttons to No, run the form - success!
Now, add the functionality: back to the VBE, open a List0_Click event
handler, remember the ListBox has no List method, wonder how to get
current item, have got ListIndex to give me the index number but what
to do with it? Notice ItemsSelected but at run-time in the click event
the ItemsSelected.Count property is zero but didn't I just trigger
this event by selecting something? At this point I give up, concluding
that MS Access forms are a totally different experience, so doing even
a simple thing throws up all kinds of issues.

--

 

[onedaywhen]

...

No. I don't. I bring the same discipline to VBA programming that
I bring to VB programming.

I hope that means you build business objects using custom classes. I
wonder that a rich form's engine with an abundance of event handlers
is a disincentive to do so.

Also :~) you would say that, being
a VB programmer

:~) VB programmers have to PLAN to avoid
repeated code. Access programmers only
have to LEARN to avoid repeated code :~)

I'm genuinely puzzled by this and would be pleased if you could
elaborate.

I just don't agree with that.

What, you don't believe I've heard that?! Here's the proof:

http://groups.google.com/groups?q="un-learn"+OR+"unlearn"+access+group:microsoft.public.sqlserver.*

--

 

[david epsom dot com dot au]

I followed that link, and the first 5+ references were to
Joe Celko :~)


On Access, Joe is a polemicist, not an authority.

I'm genuinely puzzled by this and would be pleased if you
could elaborate.

A typical 'repeated code' example in Access is someone who
has three identical tables, and three identical forms ---
one for each of the last three years. A typical 'repeated
code' example in VB is someone who has custom data validation
code on each entry field.

(david)

 

[onedaywhen]

...

On Access, Joe is a polemicist, not an authority.

An authority usually has a vested interest. Celko is an authority on
ANSI Standard SQL - there could be an analogy for us here: Celko's
main argument as I see it is, in order to ensure your code is
portable, you should use only ANSI standard SQL, SQL-92 being the
least controversial and most widely implemented. His opinion is Jet
SQL's implementation and, more importantly, common usage is so far
removed from SQL-92 to be counterproductive when it comes to learning
another product or SQL in general usage. Now, no direct comparison,
just an analogy, but I wonder if MS Access forms are so 'different'
from the other forms we've been discussing to be counterproductive
when it comes to porting etc. I understand BETAMAX was a better
implementation than VHS ...

A typical 'repeated code' example <snip>

Thanks, David. Apologies, but I'm still no clearer. Plugging your
answers back into what you originally said:

Access programmers only have to LEARN to
avoid having three identical forms, one for
each of the last three years.

What, no planning involved, just a self-fulfilling prophesy?

VB programmers have to PLAN to avoid
custom data validation code on each entry
field.

What, no learning involved because VB developers are born with the
knowledge that repeated code is bad?

Surely LEARN and PLAN are common to both?

The MS Access developer has to first learn that one generic form
should serve for all years then plan how to implement this.

The VB developer has to learn that one generic valuator should be used
for both then plan how to implement this.

Anyhow, this seems to have strayed far from my original point, which
was: if the MS Access developer has an extremely rich forms class, I
wonder if it's a disincentive to learning to build custom classes.

--

 

[Albert D. Kallal]

Been away for day..sorry I could not response sooner!

Oh well..this thread is a bit old now..but lets take a shot at this!

I use VB6 as an example because it's arguably the closest to MS
Access. Even so the forms engines are very different, and that's my
point in a nutshell. I could counter that the next 'VB6' is called
Whidbey and the next version of MS Access will be Access2000 with a
few more bolted-on tools and without the developer's version having
the redistributable runtime you will have lost more than you will have
gained, but that would be too off thread.

That is fair. However, remember we had ms-access for 10 years now. We got
dao, and when ado came along..we got that. When the VB6 language came out
we got that too. When Microsoft released sql server, then ms-access became
a client for that.

Now we are going to run under managed code in .net. It seems to me that the
path towards .net is, and will have been much less painful via ms-access,
then VB6. And, the main reason for this is that Excel and word are too
important to Microsoft...and ms-access is also part of office...so it gets
to go along for the ride. This ride is result of MS wanting to keep
Excel and word users happy! So, we had ten years..and the way
things are going now..we will get another 10 years. A rather impressive
run. Further, I don't think MS wants to repeat the forking that
occurred with VB developers when .net came along.

Incorrect. ADO, whether in MS Access or VB6, allows you to maintain
the recordset object's ActiveConnection property e.g. issuing the
Update method sends any changes to the data source, meaning a bound
recordset. And in VB6 you can associate a connected recordset with an
ActiveX control i.e. you can have bound controls too.

Actually, I need clarify what I meant by "don't *have* to" :

All I mean to has said is that in VB6 you don't have bound forms...but in
ms-access we can have a un-bound form. So WE have a choice..and
with VB6 you don't have the choice of a bound form, or un-bound.

And, to be sure a ado data control placed on a VB screen does
get you bound fields to that control. However, this is NOT the same as
having a bound form. (this difference is important, since the form
is a user UI object..where the ado data control is not (well, you
do get some navigation buttons..but the primary use of the data
control is NOT UI..where as a bound form in access is a UI
object...this distinction is important since it means that
the access form is geared towards UI).

So, a bound data form in ms-access is still a different animal
and conceptually much different then what a VB ado data control
is..

Anyway..so...I was saying that VB does
not give you a *choice* between a bound form..or not bound.

Why then is MS Access not the number one choice for SQL Server based
apps, I wonder?

Well...actually...it might be! In fact, when I look at the large number of
posts of people using ms-access with oracle here..I would easily bet that
ms-access is the most popular client to oracle NEXT to Oracles own product
line (we are talking about a non ms server product here!). In other
words...ms-access is a VERY popular client to database engines. Right now,
usually that engine is JET..but more and more it is sql server. Remember,
you have to
view ms-access as a rich data client with a VB programming language.

As a data client right now..ms-access is likely the most popular data client
in the marketplace by a large amount. Perhaps only Excel would be more
popular then ms-access in this regards.

However, ms-access *should* be used with sql server more.
One of the questions asked at the MVP summit was how to get the
message out about adp projects. (or, just the fact that you can use sql
server with ms-access). Ms-access still as general rule faces
hostility from IT debarments (the old stories about it not a robust tool..
and can't scale). Further, the IT department can't control ms-access
very well..so they don't want it. The same goes for Excel..but they
can NOT take away Excel from users! It is rather kind of sad that
so many companies ask for, and need some server client abilities with
a product..and only later realize that ms-access is a great client
and solution to many problems.

Most of the time access gets dumped on bad advice, or companies not
knowing about the ability of ms-access to work with the corporate
data server ...be it sql server or oracle. I seen this time and time again
as some consultant walks in and says that ms-access is not a secure system
or ms-access can't scale. This kind of advice is just plain
wrong, ....but one of the things that access developers encounter all the
time.

The other rumor of course was that ms-access is dead..and not
going to be supported by MS. We had that rumor for years. Of course...
with VB6 on its way out...for some strange reason we don't seem to
get that bad rumor anymore as companies upgrade to new versions
of ms-access....and more versions are on the way!

Anyway, companies that have invested 10+
years in software development using ms-access continue to get support,
and are continued to get new features year after year. A rather
impressive ride. I see another good 10 years with this product.

Also, there is also a good deal of hostility, and lack
of respect among experienced developers as to ms-access not being viewed
as a serous development tool. All the tools like the code librarian, VSS,
creating class objects etc are a part of the ms-access development
experience.

If ms-access had always been part of Visual Studio..and not part of office
..likely this lack of respect situation would not be so
bad. However, likely ms-access would not be by far and away the most
popular data client system either..so ms-access ties to office is both its
best feature..and it's worst feature at the same time..

For example, I remember that for some time dbase/FoxPro developers
will not viewed as being that serous developers. Now that FoxPro is part of
VS, then it gives it more credibility. Also, why use ms-access when it will
cut down billable hours?. I suspect that some of the hostility towards
ms-access is the "amateur" status, and that is so widely available.
Not everyone has VS on their pc..but with a large number sure
has ms-access. This tends to give the impression that the product takes no
skill to develop with. It also makes the tool *super* popular....

Incorrect. The Data Environment can be bound ASAIK and other controls
can be bound using either a ADODB Data Control or a connected
recordset object.

As mentioned...I don't consider dropping a data object on the screen and
binding controls to that a bound form. It certainly does give you bound
controls..but not bound forms. We could consider this issue just one of
semantics..but really..there is a big difference between the two.

I take up your challenge! I'll try to add a listbox to a form,
populate it manually with some items and show a message using the
selected values. Maybe the following description of my experience will
demonstrate what I've been trying to say (and/or make me look a fool
but never mind!)

I open a .mdb file in MS Access 2003. I need a form so I choose Insert
Form,

Up to the above....sounds good.

choose Design View from the unasked for wizard

Hum....not too bad...we got so far:
Insert->form->Design View->ok

At this point you get a blank form....seems good to me!

To be fair..in vb6 you are transported RIGHT into a wizard screen, and
whacking ok gets you a blank form "ready" for development. However, while
this is easy..it is also simplistic approach to starting an application....

Remember...we do inherit much of "mental model" from the office
suite....so you kind of have to think in terms of that mental model. Of
course, when using software...that "mental model" (MM) is very important. If
you are used to a desktop publishing program, and insert a picture into
that document and whack save..that picture gets saved. Now fire up a
graphical web design program and insert a picture..and
whack save...the picture does not get saved. The user will now be VERY
confused. You might say this is stupid that the program does not save the
picture when you hit save. To me..that is not bad..but just a different user
experience.

This is due to that different mental model. For both users..and developers
understanding, and being ready to change the MM is the key to learning new
concepts. So, you can read up on some of simple ideas on UI based on this MM
in this article of mine when you got a sec:

http://www.attcanada.net/~kallal.msn/Articles/UseAbility/UserFriendly.htm

close the form
expecting a save as dialog but the form has disappeared. Start again,
this time explicitly save the form by choosing Save As (I must specify
to save as a form?! Mind boggle at what else it could be!).

No, it is not mind boggling. However, you likely not used word much, or not
used Excel much? Perhaps you don't use office programs on a daily biases.
If you have used office programs...then the above concept or "MM" will
make perfect sense.

Launch excel. You will see that it opens to a blank document. Even if you go
file->new->blank workbook. Now, close excel? Notice how you get no
prompts..nothing is asked to be saved. that blank piece of whatever is
thrown away.....

The same goes for word..(try it). Launch word..go file->new...you get a
blank document..but if you close out word....no save prompts.

So, you ONLY get a save prompt if YOU MODIFY the form. If you close out that
form with no changes..then no save takes place. Most of office has worked
this way for the last 10 years (this goes back all the way to windows 3.1)

Again, this really the issue of the Mental Model we have. So,
I can't say this is a bad UI thing. So while you may
not like this different approach (mind boggle as you say), it is the fact
that all of office software tends to work this way. Office software is
arguably the most popular software in the world today and has worked
this way for a long time.

So, this "behaviors" you talk of should not surprise anyone who is going to
write software with users in mind. In fact, most users will EXPECT the above
behaviors in YOUR software you write. Thus, you should seek to emulate
this behaviors for your users also when writing software also.

I remember how difficult it was for some dos based FoxPro/dbase
developers to make the leap to "event driven" programming that ms-access
offered. It was a very large change in the users MM, and caused a lot of
grief for these developers. So, while you may find the change to ms-access
different...most software developers SHOULD as a matter of design concepts
adopt the MM way of how office works..since that is what most people use.

Form is
now closed and saved. Choose View, Code: MS Access goes GPF

Gee..that sucks ..don't it!!!

At least I can say that we now have Dr. Watson integrated into office..and I
hope you whacked "send report". MS will watch the frequently of reports
of your problem..and that data sent will help MS to make a fix. Stuff like
Dr. Watson integrated into improving products like ms-access is a revolution
into software quality...something that other competitors to ms need to
learn.

However..I also had a few GPF errors in a2003..and I hope it is something
with
my install. I will say that a2003 is rather new...but it is not
re-assuming. Most my dev is with a2002..and it is very solid for me.

I guess the first release of the .net tools was quite nasty also....but I
not
going to make any excuses here.....(that is yuk!).

Anyway..your above steps DO NOT gpf on my pc..(I am using a2003
here!).....my a2003 seems ok stability wise..

Ok..so at this point we got that blank form in design mode. (and, like word,
excel, and most software if you close it..you loose it..since you done
nothing).

Note also how we get a instant project..since any form,
report etc is PART of that ONE file wonder. In one slice of the knife, we
have a full project file..and don't have to worry about all the pieces..as
they are in a nice container. So, you do NOT have at this point be burdened
with choosing a file LOCATION. Since the whole thing is ONE
thing!.

See, we are already saving development time
here..and don't even need to create a folder to hold all this stuff!

So, that mdb file is a instant project. You can email it, you can
grab and copy the WHOLE application by simply copying the file, and that is
a
LOT easier then copying a whole bunch of files/folders in a dir. Further ,
you can
copy that file to another pc..and it just runs!. This one file wonder of a
mdb is perhaps another one of those great software revolutions that
ms-access
has.

And, look how easy it is to send the application somewhere else! People in
..net
are just now starting to talk about the wonders of x-copy development and
the
end of having to create a install routine. Here is my file..just run
it....great new world awaits us developers in this regards (but access folks
have had this for ten years now).

finally get the VB editor to open.

At this point...we normally don't go to the vb editor. We would simply drag
the listbox from the tools onto the form. In fact, you select the listbox,
and then click on the form (same as in vb)

Further..we do NOT have the same concept as a run button for our forms
(in VB, both code, and the forms are executed via the "play"/run button).

In ms-access, a form is not "run",but simply flipped into view mode.

Again, this process is much nicer in ms-access. However, it is different
but also better! Why? Because then I can navigate through 6 or 7 forms
deep..and then whack the design button.

Oh boy..I always missed this ability in vb...you navigate your way to a spot
in deep into the application...and then need to change code, or something on
the form.......(how do you get that spot in VB). In ms-access..you simply
whack
the design button, and what you are looking at is now in development mode.
Heck, this means you don't even have to remember or KNOW the name
of the form you are looking at when you want to change it!!! This unloads
a large amount of mental effort during development. My last application
that is considered SMALL for ms-access had a 160 forms, and yet the
resulting application can be zipped onto a single floppy disk. With
that many forms...I don't even how to worry, or remember the form
names to modify..I simply navigate via the application to where I want
to go..and then jump right into design mode. Just fab this is! And,
those 160 forms took less then 1/3 the time to develop. (actually,
it is likely a greater factor then that).

So, sight differ model..but one that lets you jump into design mode at
any point...all IDE's should work this way!

This response of mine is already getting too long here! Anyway,
I find the switch between design, and run mode far more fluid
and easy in ms-access then just about all other IDE's I used...

Phew! Choose List0 from the
objects, look at the events: seems to be the normal quota, wonder
where are all the extra events I've heard about? In the Form_Load
event, add some items e.g.

Actually, you should be looking at the form in design mode..and select
the listbox on the tool bar..and then just draw the listbox on the listbox
onto the form. And..you should likely use the wizard the first
few times (the wizard means the Accounting guy down the hall who has
never coded can do this also!).

With List0
.AddItem "One"
.AddItem "Day"
.AddItem "When"
End With

You actually don't need any code....after you drop the listbox on the
form...right click on the listbox control and select properties (and your
properties window appears). Now on the data tab....set the row
source type to value list.

On the next line in the properties sheet called Row Source..just type:

One, Two, Three

You are done. Notice how we have ZERO lines of code. In fact, if you do set
the listbox setting as value list..then in code you COULD go in the forms
on-load event:

me.List0.RowSource = "One, Two, Three"

So, the above is ONE line of code. That is still %500 less code then your
example code of 5 lines (so far). That is 5 times less so far!

Want to test the form, press the 'VCR Play' button, doesn't run the
form but brings up a blank list of macros.

Yes..as mentioned we don't run a form..but simply flip the form from design
mode into form view. And, as mentioned, if you are following my steps
above..we have not YET even seen the VB IDE if you use my above
code-less solution. And, if you do use the above code solution..you
are still at one line of code.

You have to remember, that our forms do NOT necessary
need to have ANY code at all to function! A form can
have zero code if you wish..and still do useful things like
edit data!

Once again you have a different MM here. So, you don't
run forms..but simply view them. (and..what could be
more natural?). I can assure you during
development.this saves tons of time..and is MUCH faster to flip into
design mode the it is into "run" mode that VB has.

OK, so add a standard
module, add a public sub named 'Test' to show the form from here. Try
Form1 but haven't got that object, notice in the VBE its called
Form_Form1 (why?!),

Well, because each form you make in ms-access that has code becomes a class
object of name "form_YouFormName". So, each form is a class object, and
any public code function becomes a method of that form. (this is also how
VB works..but you don't get a class object name as above...in VB the
form name becomes the class object). (there is several reasons why
this is done..but again ...my post is already too long...one reason
likely is that forms can be code-less).

OK that's a public object but it hasn't got a Show
method, look for something else (notice it has many properties named
as if they were events e.g. AfterUpdate, BeforeInsert, etc - weird!),

Ah...see..there is all that extra stuff I was talking about! All
forms have those extra methods..and properties....there is
lots of extra stuff here!

try to load it:

Load Form_Form1

The access IDE is VB6 (and I am told that the compiler and code system is
actually the SAME CODE base as VB6. So, you have load..but
load is for user forms..and NOT ms-access forms....so..do not use load
.......it is there..but not for us!).

To open a form..you use:

docmd.OpenForm "form1"

At first think it hasn't worked but the form is shown behind the VBE
window (!!). Success! But there is something that looks like the ADOBC
Data Control at the bottom of the form, that will have to go. Go to
the form designer again

yes..while looking at the form..right click..and select design view....
(much better then closing the form as you must in VB). Once you
get the hange of right-click->design..you will like this.

look at the form properties, can't see anything, look again and
realize I must change drop down to 'Form' (why?!)

Great question! In VB you can simply click anywhere on the form
and you have now selected the form. The problem is with ms-access
forms, you click on the form..you have selected the detail section of that
form.
That detail section has all the standard events (click, double click, on
mouse down etc. And that detail section also has all kinds of properties
you can set also (back color,, back imaging....etc.....quite a bit of
stuff).

You have all of this features in VB forms..but you don't have 5 sections!
If you go view-header/footer, you will see that you can click on the
header (it also has it own click event...along with all kinds of
propriety).
If you click on the footer section, then once again you get all the events
and properties. So...you got 5 sections to deal with.
(see, I told you those access forms are more complex).

So, all of the events and properties apply to each section of the form.
VB forms are one simple thing.....and thus very simple...

The ms-access form has header, footer, page header, page
footer. So, that is why you can't just click on the form and then use/set
the properties of the form..since our forms are so much more complex.

By the way, those form headers and footers can do some real cool things
for you. For example, you can use the footer of a form to generate totals
on a invoice form..and once NO CODE is needed to do this. Again,
you learn to use those sections correctly..you will eliminate TONS of code!
Imagine that...the form footer can generate totals of data for you with
out using code!

And, having sections also gives developers a very nice organizing of
the form. I mean, obviously things like text heading that explains
what the form does etc goes in the heading part. And, detail section
usually has the data controls in it. This is again why I see so much
better data applications written in access (in VB..there is no structure
to the form design). And, you are free to put data contorsl in the headder
or footer if you wish (but as mentioned some things will behavie differllty)

Anyway, it is rather incredible that those sections can be used to sum
totals
etc without the need for code. If you look at the last screen on the
following
page..you will see a typical invoice/detail form. Those totals (total paid
etc). on the bottom of the payment details took NO code to create!
By the way, you can see the use of lots of sections in that form
also. And, further...that form has about 5 sub-forms. This means that
the form is again managing relations between data (the database relations
between 5 tables are managed for me in this case also).

http://www.attcanada.net/~kallal.msn/Search/index.html

So, now that you realize why clicking on a form dos not select
the form..you do have some shortcuts to select the form:

You can quickly select the form by going ctrl-r, or
simply whack the square in the upper left hand corner of
the screen (that is usually what I use).

So, we have form sections..and as mentioned they once
again force a very nice consistent design through out the application

At this point I give up, concluding
that MS Access forms are a totally different experience, so doing even
a simple thing throws up all kinds of issues.

I can only say that I demonstrated how to fill that list box with zero lines
of code..or one line of code if we choose to do so. And, I explained
the fact that our forms have several sections to them, and again this
feature results in incredible gains in productivity. The VB forms
are not even close.....

And, I should point out that those native controls to ms-access are in
fact NOT activeX controls. So, you do have to learn a different approach
here. (by the way..you can insert activeX controls..but then you now
need a install routine to deploy the application...(that means the
developer edition of ms-access is needed if you start using real
activeX controls).

And, really..try making a listbox with the wizard..and see the results you
get. Of course...using the wizard to make your listbox means that
anyone who can use a mouse can build that listbox..and
not even know how to code....

Also...my apologies for the length of this post.....if my writing skills
where half as good as my coding skills...I would take the some to
shorten this post by 1/2... (sorry for the length...).

 

[Brendan Reynolds]

If you were to take that argument through to its ultimate conclusion, we'd
all be writing "standard" BASIC, shunning "proprietary", "non-standard" VB
keywords in case we might someday have to port our code to some other
version of BASIC.

Portability is not everything. There are a lot of Access/Jet apps out there
that have been meeting customers' needs for years, and will continue to meet
them for years to come. You have to balance the possible future benefits of
portability against the concrete and immediate benefits of rapid
development. Portability is only of value if and when the app is actually
ported. You can have the most portable code ever written, but it will be of
no benefit to anyone if the code is never actually ported.

And I think flexibility is one of the most valuable skills for a developer
to learn. Learning to switch between Jet SQL and T-SQL, or VB forms, .NET
Windows Forms, .NET Web Forms and Access forms, may not be easy, but I think
it is a more valuable skill to learn in the long run than doggedly sticking
to a 12-year old standard.

--
Brendan Reynolds (MVP)
http://brenreyn.blogspot.com

The spammers and script-kiddies have succeeded in making it impossible for
me to use a real e-mail address in public newsgroups. E-mail replies to
this post will be deleted without being read. Any e-mail claiming to be
from brenreyn at indigo dot ie that is not digitally signed by me with a
GlobalSign digital certificate is a forgery and should be deleted without
being read. Follow-up questions should in general be posted to the
newsgroup, but if you have a good reason to send me e-mail, you'll find
a useable e-mail address at the URL above.

 

[onedaywhen]

...

Much of your post confirms my point: that MS Access forms are too
different from its closest equivalents (e.g. Word/Excel userforms, VB6
forms, Windows forms in .NET etc) for me to consider learning. My loss
<g>.

Selected quotes:

a bound data form in ms-access is still a different animal
and conceptually much different then what a VB ado
data control is ...
really..there is a big difference between the two.

we do NOT have the same concept as a run button for our forms

you have load..but
load is for user forms..and NOT ms-access forms ...
To open a form you use...

those native controls to ms-access are in
fact NOT activeX controls. So, you do have
to learn a different approach

you should likely use the wizard the first
few times

I don't want to use wizards if I can help it, especially if MS Access
is hiding things from me (I'm not the guy from Accounts, I can handle
the complexities!)

You actually don't need any code. ..

I don't want to set too many form properties, I *want* to write code
and I want that code to be broadly similar to the aforementioned forms
so that if don't have to change much when the time comes to port my
code.

--

 

[onedaywhen]

...

If you were to take that argument
through to its ultimate conclusion <snip>

It was an analogy, not an argument. It's a feature of analogies, I'm
afraid, they don't stand up to that kind of treatment.

Portability is not everything.

'I Will Never Have To Port This Code':
http://www.intelligententerprise.com/030422/607celko1_1.jhtml

Maybe I should have used the word 'compatible'. If I have a product
which supports a variety of DBMS products, I find it useful to use
SQL-92 syntax because I know I will only have to write one set of
queries - oh yeah, plus an extra set for Jet.

Why do you think XML is so central to the .NET framework?

doggedly sticking to a 12-year old standard

The standard may have been set down a long time ago but we're still
waiting for even the 'big' DBMSs to fully implement it.

--

 

[david epsom dot com dot au]

wonder if it's a disincentive to learning to build custom classes.


When you move to another environment, knowledge of a rich data
validation object is an immediate incentive to build and use
your own.

(david)

 

[onedaywhen]

...

When you move to another environment, knowledge of a rich data
validation object is an immediate incentive to build and use
your own.

Another good point.

Thanks david, and Albert. My knowledge of MS Access forms is now
greatly enhanced as a result of this discussion.

--

 

[Brendan Reynolds]

A quote from the article at the URL you posted ...

"Unless you throw out a program within a year of writing it, it's either
going to be ported or so seriously maintained it might as well be a port."

This is simply not true in my experience. I know of at least one application
that I developed back in the mid-nineties that is still in daily use, and
the only "port" it has ever gone through was from Access 95 to Access 97 - a
trivial process.

Now I am not denying the possibility that it may be ported, someday. The
point is that even if it is ported, and even if that process does require a
major rewrite, or even a replacement, the client will still have received
value for money. I produced that app quickly, cheaply, and it has satisfied
their needs for some eight to nine years.

Certainly, if I can achieve the same result, as effectively, without using
proprietary features, I will do so. But if I see a productivity advantage in
using the proprietary feature, I will not hesitate to use it.

Similarly on the issue of skill-sets and experience. My knowledge of Access
and of Jet has enabled me to earn my living while doing work that I (mostly
! enjoy for several years. If I had to switch to another tool tomorrow,
and unlearn everything I ever learned about Access and Jet, I would have no
complaints - it would have been worth it. I have, in fact, spent more time
in recent months working with C# and ASP.NET than with Access. Do I regret
any of the time I spent learning about Access and Jet? Not for a moment!

--
Brendan Reynolds (MVP)
http://brenreyn.blogspot.com

The spammers and script-kiddies have succeeded in making it impossible for
me to use a real e-mail address in public newsgroups. E-mail replies to
this post will be deleted without being read. Any e-mail claiming to be
from brenreyn at indigo dot ie that is not digitally signed by me with a
GlobalSign digital certificate is a forgery and should be deleted without
being read. Follow-up questions should in general be posted to the
newsgroup, but if you have a good reason to send me e-mail, you'll find
a useable e-mail address at the URL above.

 

[onedaywhen]

...

if I can achieve the same result, as effectively, without using
proprietary features, I will do so. But if I see a productivity advantage in
using the proprietary feature, I will not hesitate to use it.

This very recent Celko post seems to sum up the issues you don't seems to be seeing:

http://groups.google.com/[email protected]

<quote>There is no FROM clause in a Standard SQL
UPDATE statement; it would make no sense. Other products (SQL Server,
Sybase and Ingres) also use the UPDATE .. FROM syntax, but with
different semantics. So it does not port, or even worse, when you do
move it, it trashes your database. Other programmers cannot read it and
maintaining it is harder. And when Microsoft decides to change it, you
will have to do a re-write.</quote>

--