Re: Starting with VB2005 and SQL Server 2008 Express Edition

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"NZSchoolTech" <nzschooltech@xxxxxxxxxxxx> wrote in message
news:%23WlVhP9wJHA.3676@xxxxxxxxxxxxxxxxxxxxxxx

It's been apparent to me for years and years and years of using Access
that
MS have basically built it as a stripped down version of VB, and many of
its
limitations are built in intentionally to get people to scale up to VB if
they need more functionality. Obviously going in VB is more work. We have
Access volume licensed across our site (this is an in house application)
so
the licensing cost is not an issue.

So if you can address those points further that would help me to get
somewhere closer to the answer that I need.


As far as a "Development Platform" you are at the cross-roads of several
different technologies (some roads going out are rocky and narrow, but
promise eventual access to a broad interstate, and others nicely paved but
likely lead to a dead end), and thus have to make a decision that will not
only have a dramatic short-term effect, but will have long-term consequences
as well. However, take comfort that you are not alone. Every MS Access
developer is in the same situation today.

The "Visual Basic" languages.

"Visual Basic" is a registered trade-mark of Microsoft. They are the
soul-proprietors of the language and they can do with it as they will. They
use that name to describe all the various dialects of "Visual Basic". But
note there has never been a formal or standard for the language. As
programmers we tend to think of a language as the soul factor in a
development platform and forget it is only the "front-end". It is how we
provide instructions for the underlying tools to compile or assemble to
produce a product.

All "Visual Basic" languages while similar in style and semantics need to be
thought of only in terms of the specific platform they are used in. If you
do that, then you won't get confused as you consider your options.

MS Access uses for it's internal programming VBA (Visual Basic for
Applications). VBA is a sub-set of VB "Visual Basic" the original VB
COM-based development platform (for lack of a better definition; often
referred to as 'Classic VB'). This included versions VB1.1 to VB6. The
latest being VB6 which came free-standing or part of Visual Studio 6 (which
included Visual Basic, Visual C++, a various support packages (MFC, VSS,
....).

VBA for Access has the same parser and editor as VB6 and both languages as
well as their development environment share many similarities. I winced with
the characterization that VBA for Access is a "stripped down version of VB".
It is more accurate to note that VB6 is nothing more than "VBA for VB" -
different only through their respective object models, runtimes, and
products.

The VB6 development plaform has been discontinued by MS. It is gone.
However, since it is was once the most popular development language/platform
in the world, there are many people who still use it. And VB-generated
applications, dlls, runtimes, and other components are still supported to
some degree. You can still use VB6 to develop applications, but you are
looking at an dismal future.

Microsoft's new (while if you consider 'new' as the last 10 years lol)
development platform is based on the .Net Framework library. These platforms
use a very different compiler and tools. And while they provided a
semantically similar "Visual Basic" language for this platform it should
never be confused with VB or VBA. From now on I'll refer to it as "VB.Net".

This was all well and good for "Visual Studios" but what about Office
products and their need for an internal 'macro' language. It is MS's
intention to replace VBA with .Net Framework solutions - possibly VB.Net (or
even C#).
[It should be noted that the .Net Framework development environment is
essentially neutral in terms of the programming language you use. For
example, you can create a .Net application using modules written with C# or
VB.Net (or any of about a half dozen others) all in the same program.]

But that part has been slow in coming. VBA is still king. But eventually MS
will have their way.

As you are not now fluent with VBA, and considering the poor future of VB, I
suggest that if you use a separate development platform for tools outside MS
Access - you go ahead with learning "Visual Basic 2005/x". The learning
curve from VBA will be sharper that perhaps learning VB, but you'll have to
go there eventally.

[As I noted before, no matter what product you go with VB or VB.Net you will
still need to purchase an outside report generator, therefore ...]

For your situation I suggest sticking with the MS Access development
platform or more correctly with MS Access Projects. You already know MS
Access. All your users have access to MS Access and presumbably know how to
use it. You can use MS Access Projects as a front-end to database servers.

You can create a robust multi-user application suite now with the tools you
know and have available. In the meantime you can start learning and
familarize yourself with MS's .Net Framework for additional support.

As well as spending some time learning the nuances of your chossen backend
server and designing strategies to manage multi-users.

Whew!

Hope this has been helpful...
-ralph








.

Relevant Pages

  • Re: Why to use VBA?
    ... all I am saying is its time to start introducing new features in .net that will do the same thing VBA does and give the market time to accept it without dropping VBA as you said executives are conservative to change VBA! ... The fact is that VB.NET is sufficiently incompatible with the previous version of VB (VB6, from which VBA is derived) that for all practical purposes an upgrade wasn't possible, you had to rewrite the code more or less from scratch. ... The automated code converters provided by Microsoft were next to useless, and the fact that Microsoft went and changed lots of names of objects and properties meant that late-binding code wouldn't work without rewrite because it couldn't be automatically converted at all. ... Lots of people asked Microsoft what that reason was, with regard to that and dozens of other changes to the language. ...
    (microsoft.public.word.vba.general)
  • Re: Why to use VBA?
    ... MS can not keep VBA for 20 years no technology will remain more than 5 or 6 years in computing field! ... The fact is that VB.NET is sufficiently incompatible with the previous version of VB (VB6, from which VBA is derived) that for all practical purposes an upgrade wasn't possible, you had to rewrite the code more or less from scratch. ... The automated code converters provided by Microsoft were next to useless, and the fact that Microsoft went and changed lots of names of objects and properties meant that late-binding code wouldn't work without rewrite because it couldn't be automatically converted at all. ... Lots of people asked Microsoft what that reason was, with regard to that and dozens of other changes to the language. ...
    (microsoft.public.word.vba.general)
  • Re: Just what is "Visual Basic for Applications"
    ... Can somebody please clarify for me (multiple corroborating responses ... VB6 and VBA share the same syntax and language engine but have a different ...
    (microsoft.public.vb.general.discussion)
  • Re: Slower and Slower
    ... All the things you mentioned are not language features -- ... they're features provided by the VB6 environment. ... Yes, you load up the Object Browser, select VB or VBA, and you see what you ...
    (microsoft.public.vb.general.discussion)
  • Re: Why to use VBA?
    ... c# is not suited to be the only language to write eneterprise Apps or system Programms! ... 1- use existing vba apps with new versions of office ... If Microsoft were to rewrite Office using the .NET platfrm instead of the ActiveX platform it uses now, they would probably be 4 years doing the rewrite with no features added. ...
    (microsoft.public.word.vba.general)