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

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)

"Brian" <(E-Mail Removed)> wrote in message
news:85f001c4325a$4a4ea510$(E-Mail Removed)...
> 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" <david@epsomdotcomdotau> wrote in message news:<(E-Mail Removed)>...

> 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 wrote:

> 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.

--

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.

> > 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.

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...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(E-Mail Removed)
http://www.attcanada.net/~kallal.msn

> 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.

--

"onedaywhen" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> 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!).

> > "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.

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.


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(E-Mail Removed)
http://www.attcanada.net/~kallal.msn

> "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.

--

> 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)




"onedaywhen" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> > "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.
>
> --

"david epsom dot com dot au" wrote ...

> > 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.

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

Presumptuous <g>.

> :~) 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've heard say it takes a good part
> > of a year to 'un-learn'

> 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=%2...ic.sqlserver.*

--