access vs visual basic 6.0 vs visual basic.net

access vs visual basic 6.0 vs visual basic.net

Post by Bria » Thu, 06 May 2004 13:34:44


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 vs visual basic 6.0 vs visual basic.net

Post by david epso » Thu, 06 May 2004 15:50:50

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)

 
 
 

access vs visual basic 6.0 vs visual basic.net

Post by onedaywhe » Fri, 07 May 2004 00:38:26


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.
 
 
 

access vs visual basic 6.0 vs visual basic.net

Post by onedaywhe » Fri, 07 May 2004 00:41:37


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

access vs visual basic 6.0 vs visual basic.net

Post by Albert D. » Fri, 07 May 2004 04:21:27

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.yqcomputer.com/ ~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...
 
 
 

access vs visual basic 6.0 vs visual basic.net

Post by onedaywhe » Fri, 07 May 2004 18:17:35

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

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:


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.


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


Hmmm.


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

access vs visual basic 6.0 vs visual basic.net

Post by Albert D. » Sun, 09 May 2004 08:53:50

onedaywhen" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


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?


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.


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.


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.


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 ser
 
 
 

access vs visual basic 6.0 vs visual basic.net

Post by onedaywhe » Tue, 11 May 2004 19:34:11

gt; "Albert D. Kallal" wrote ...

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


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!


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.


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


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


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


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.


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


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?


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.


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
t
 
 
 

access vs visual basic 6.0 vs visual basic.net

Post by david epso » Wed, 12 May 2004 10:52:40

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

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 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" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


 
 
 

access vs visual basic 6.0 vs visual basic.net

Post by onedaywhe » Wed, 12 May 2004 17:48:02

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



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.


Presumptuous <g>.


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



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

http://www.yqcomputer.com/ %22un-learn%22+OR+%22unlearn%22+access+group:microsoft.public.sqlserver.*
 
 
 

access vs visual basic 6.0 vs visual basic.net

Post by david epso » Thu, 13 May 2004 11:06:48

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


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



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)




http://www.yqcomputer.com/ %22un-learn%22+OR+%22unlearn%22+access+group:microsoft.public.sqlserver.*
 
 
 

access vs visual basic 6.0 vs visual basic.net

Post by onedaywhe » Thu, 13 May 2004 17:53:48

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


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


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


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


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.
 
 
 

access vs visual basic 6.0 vs visual basic.net

Post by Albert D. » Thu, 13 May 2004 18:51:47

een 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!

"onedaywhen" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


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.


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.


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
 
 
 

access vs visual basic 6.0 vs visual basic.net

Post by Brendan Re » Thu, 13 May 2004 19:32:40

f 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" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


 
 
 

access vs visual basic 6.0 vs visual basic.net

Post by onedaywhe » Fri, 14 May 2004 00:32:13

"Albert D. Kallal" wrote ...

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:






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


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.