Access awake after 7 years?
AnandaSim
Rucker's blog entry and the new Jet:
http://blogs.msdn.com/access/archive/2005/10/05/477549.aspx
mentioned by Mike Gunderloy
http://www.larkware.com/dg4/TheDailyGrind726.html
Aside from the Sharepoint feature extension, amazing news.
Ananda
Allen Browne
Access.
Erik mentions the size of the Access dev team, and promises more info about
developments with the JET engine.
Really early days yet, with many months before the next version is out, but
Microsoft has been listening to user feedback, and will be providing some of
the most asked for features, including the ability to create PDFs out of
Access.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"AnandaSim" <Anan...@gmail.com> wrote in message
news:1128664355.8...@z14g2000cwz.googlegroups.com...
Ananda Sim
BTW, use some of your tips all the time...
Allen Browne wrote:
> Yes, there are some *really* exciting developments taking place in the next
> Access.
>
> Erik mentions the size of the Access dev team, and promises more info about
> developments with the JET engine.
He makes the point that the team has increased seven fold. I joke that
the team is now seven strong. <grin>
>
> Really early days yet, with many months before the next version is out, but
> Microsoft has been listening to user feedback, and will be providing some of
> the most asked for features, including the ability to create PDFs out of
> Access.
>
I am a little blasé with adding feature width (Data Access Pages,
SharePoint extensions etc...) and more interested in feature depth
(programmable pdf printing, object dependencies, form and report design
undo).
If Jet can now grow and/or we can see some lean towards LINQ
http://msdn.microsoft.com/netframework/future/linq/
and encapsulation of the XML apps (RSS, XML databases, ADO.NET
structures) that would be good.
But how will the solve the VBA vs COM dilemma? I guess Office 12 is
still COM, so how do they nurture VBA or replace it with .NET tools?
We live in exciting times!
Larry Linson
I think you'll find that the seven-fold increased development team totals
more than seven. <GRIN>
You can expect VBA to be around for a while, but that doesn't rule out some
Dot Net interaction (see the current Visual Studio Tools for Office support
for VB.NET and C# with Word and Excel).
I will have to be convinced that LINQ is an improvement over SQL for
databases. As I understand it, if you have the need, it allows database-like
access to other entities besides databases. Frankly, I have never had such a
need in any Access application on which I worked.
Larry Linson
Microsoft Access MVP
aaron...@gmail.com
ACCESS ALREADY WENT THROUGH THE AMAZING CHANGES THAT YOU ARE WAITING
FOR.
IT IS CALLED 'ACCESS DATA PROJECTS' and 'DATA ACCESS PAGES'. It came
out with offfice 2000; but it really became an awesome product with the
release of Access XP.
you closed-minded MVPs should go and take a long walk off of a short
pier.
I'm sorry that you MVPs _ARENT SMART ENOUGH_ to learn ADP and DAP.
get over it. The future was 5 years ago!!!!
Bob Alston
don't think so, go out and find a web host that will allow DAPs.
Bob
Ananda Sim
disenchantment with ADPs and DAPs. I did and I'm not an MVP.
Ananda
Ananda Sim
Larry Linson wrote:
> I think you'll find that the seven-fold increased development team totals
> more than seven. <GRIN>
Ok, I'll bite. How many are there? Could we expect to see improvements
to the venerable Expression Builder and have dual fonts - one for the
Design View and one for the SQL View of the Query Design.
>
> You can expect VBA to be around for a while, but that doesn't rule out some
> Dot Net interaction (see the current Visual Studio Tools for Office support
> for VB.NET and C# with Word and Excel).
Yes, all excited about the dot net interaction. But we need practice and
VSTO is AFAIK not free but an extra cost item to Office?
>
> I will have to be convinced that LINQ is an improvement over SQL for
> databases. As I understand it, if you have the need, it allows database-like
> access to other entities besides databases. Frankly, I have never had such a
> need in any Access application on which I worked.
Not in that regard - although it would be nice. I was impressed that
instead of
strSQL="select * from customers"
db.execute strSQL
in which strSQL is a string and therefore unverifiable,
LINQ to me looks like it can be:
Dim dbNorthwind as Database
Dim tblCustomer as Table
Dim rstCustomers as Recordset
set dbNorthwind = currentDB
set tblCustomer = Northwind.Table
set rstCustomers = SELECT * FROM tblCustomer
well, this is all made up but you get what I mean - instead of using
strings to encapsulate SQL, you instantiate LINQ objects and use an SQL
like syntax to bind resultsets - you aren't writing SQL, you're writing
SQL like syntax.
And the IDE because it knows system and user defined objects, will parse
and verify your syntax.
Unless of course, I completely missed Anders H.'s point - he is such a
brain.
Ananda
Larry Linson
> He's also flung dung at the wrong people.
> Neither of the MVPs expressed
> disenchantment with ADPs and DAPs.
> I did and I'm not an MVP.
Poor aaron, he drank the Kool-Aid 'way too soon. He wholeheartedly swallowed
the marketing hype on features that never proved their worth. But, clearly,
anyone who makes the grandiose claims he does can not possibly have used
those features to any significant extent.
Without violating my non-disclosure agreement, I think I can safely say he
is going to be disappointed if he is hoping for ADP and DAP to be "the
Access of the future". Lyle Fairfield was initially a strong supporter of
ADP, but has eloquently described ADPs fatal shortcoming, right here in this
newsgroup -- apparently aaron hasn't read Lyle's posts. Or, perhaps data
security is not an issue for aaron.
David W. Fenton
news:43461491$0$19777$5a62...@per-qv1-newsreader-01.iinet.net.au:
> Really early days yet, with many months before the next version is
> out, but Microsoft has been listening to user feedback, and will
> be providing some of the most asked for features, including the
> ability to create PDFs out of Access.
I saw that in the Word 12 preview information, too. But I wonder if
that means that Microsoft is abandoning their competitor to PDF?
That would be good news if it's the case.
The one thing I miss in Erik Rucker's post is a mentione of a
commitment to the developer side of things, especially the developer
working with small businesses. Access has de-emphasized that market
since the introduction of A2K, which seemed to me to be very
enterprise-oriented, with all the new features (except for those in
Jet 4 itself) directed towards interoperability with SQL Server.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Steve Jorgensen
I have it on good aouthority that the following occurred...
An acquaintance of mine in PAUG (Portland Access Users Group) was asked to go
visit Microsoft and explain to them why there was so little interest among
Access developers in upgrading to new versions, particularly Access 2003. His
response to Microsoft was that nothing added to Access 2003 made it
particularly easier to create applications or allowed us to add any value for
the user. He then gave them a list of features he'd been wanting to see since
Access 97, and things that were useful in Access 97 that have been broken ever
since.
I thnk it's a good sign that since MS percieved a problem with lack of
interest in Access 2003 and asked at least one professional Access developer
for advice.
WJA
what the default file format will be in the next version? Will MS
stick to A2K or are they going to wipe the slate clean? It will be
great to have added functionality in the development environment, but
will this only be usable if the user is running the new version of
Access on their PC?
>From my experience, companies don't race out and purchase the latest
version of Office as soon as it hits the shelves. Many that I know of
are using Office XP and some are still using Office 2K.
At the moment a developer can develop the application with Access 2003
and still distribute it to clients who are using the older versions if
he/she sticks with Access 2K file format and uses the relevant older
version to create the mde. Will this continue?
Steve Jorgensen
And you've had it work reliably? I've never had much luck with that. It does
seem to work, however, to develop in A2K3, recompile in A2K2, and deploy that.
lylefair
Please, tell us those web hosts which do not allow DAPs.
Rick Brandt
A serious developer should own all of the Access versions and deliver a file
that he knows will work for the user. If you do that then the fact that a newer
version uses a file format that is not compatible with all of your users is not
a problem. You simply don't develop in that version except to create apps for
users who also have that version (or a compatible version).
If you want to immediately acquire the latest version when it comes out and
learn all of the ins and outs that is commendable. It doesn't necessarily
follow that the newest release should become the development platform for all of
your users.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
lylefair
Bob Alston wrote:
> But DAPs don't work for anything other than a LAN based web sit. If you
> don't think so, go out and find a web host that will allow DAPs.
I have a second question: DAPs are files with a .htm extension. How
does the web host identify the DAP?
lylefair
Rick Brandt wrote:
> A serious developer should own all of the Access versions and deliver a file
> that he knows will work for the user. If you do that then the fact that a newer
> version uses a file format that is not compatible with all of your users is not
> a problem. You simply don't develop in that version except to create apps for
> users who also have that version (or a compatible version).
I think your logic supports the retention of Clipper for those clients
who have DOS based machines. Great! I love Clipper.
But then what if they have only Commodore 64's? Ah well, there was a db
for the Commodore 64 called Oracle (no Really, it WAS called Oracle!)
with the wonderful ability of being able to cut and paste rectangles of
the screen as text (or was that PaperClip?). So, I should dust off the
machine in the basement?
David W. Fenton
news:4R72f.3$q%.2@newssvr12.news.prodigy.com:
> WJA wrote:
>> I guess I'm just thinking out loud here but does anyone have any
>> idea what the default file format will be in the next version?
>> Will MS stick to A2K or are they going to wipe the slate clean?
>> It will be great to have added functionality in the development
>> environment, but will this only be usable if the user is running
>> the new version of Access on their PC?
>>
>> > From my experience, companies don't race out and purchase the
>> > latest
>> version of Office as soon as it hits the shelves. Many that I
>> know of are using Office XP and some are still using Office 2K.
>>
>> At the moment a developer can develop the application with Access
>> 2003 and still distribute it to clients who are using the older
>> versions if he/she sticks with Access 2K file format and uses the
>> relevant older version to create the mde. Will this continue?
>
> A serious developer should own all of the Access versions and
> deliver a file that he knows will work for the user. . . . .
Well, if that's a Boolean AND, then I'm not a serious developer, as
I don't own any version of Access beyond 2000. I develop in that
where necessary and deploy on A2K2 or A2K3 where necessary. My
clients using something beyond A2K provide me Terminal Server access
to administer and test the apps on the versions they are deploying
under.
> . . . If you do
> that then the fact that a newer version uses a file format that is
> not compatible with all of your users is not a problem. You
> simply don't develop in that version except to create apps for
> users who also have that version (or a compatible version).
I see no reason whatsoever to use the A2K2 or A2K3 file formats. Why
restrict your deployment platform for such a paltry collection of
new features?
> If you want to immediately acquire the latest version when it
> comes out and learn all of the ins and outs that is commendable.
> It doesn't necessarily follow that the newest release should
> become the development platform for all of your users.
I am conservative about recommending upgrades, but with the
stability of A2K as default MDB format for all versions since A2K, I
suggest that those who are already at A2K go ahead and upgrade when
purchasing new PCs, rather than the old practice of buying the new
version, removing it and installing the older version.
David W. Fenton
news:1128857753.7...@g49g2000cwa.googlegroups.com:
> DIscountASP.Net allows DAPs.
>
> Please, tell us those web hosts which do not allow DAPs.
Every web host that's running a safe HTTP server.
That is, any web host that's running Apache, for instance.
Any web host that's running IIS is not one I'd ever use, because I
don't want my sites exposed to the vulnerabilities that come with
IIS.
David W. Fenton
news:1128884032....@g43g2000cwa.googlegroups.com:
Well, they have to support Jet databases, as well. I don't know how
DAPs connect to the MDB file, but I doubt it's ODBC, which is the
most widely-supported interface for Jet databases (available even on
some non-Microsoft-based web hosts).
Rick Brandt
Okay, take a reasonable argument and stretch it to the ridiculous. The issue
was clearly Access apps and the OP's concern was "What do I do if the new
version is a different format that my users don't have?". The answer to that is
simple, you develop a version that they can use.
It is reasonable to assume that you will encounter many users who still have
Office 97. It is not reasonable to assume that many of your users will be
running Windows 3.1 or DOS 6.0.
Steve Jorgensen
<dXXXf...@bway.net.invalid> wrote:
...
>Well, if that's a Boolean AND, then I'm not a serious developer, as
>I don't own any version of Access beyond 2000. I develop in that
>where necessary and deploy on A2K2 or A2K3 where necessary. My
>clients using something beyond A2K provide me Terminal Server access
>to administer and test the apps on the versions they are deploying
>under.
Personally, I find A2K too flakey to work in. A2K2 is far more stable. I've
been able to convince most of my clients to switch to A2K2 or A2K3.
I develop almost exclusively in A2K2 now, and use the 2K2 file format to keep
people from running it under A2K since I didn't test it in A2K, and there's a
good chance that won't work.
Rick Brandt
That is not the argument I intended to convey. You can deliver an app that will
work for all of your users without owning A2K2 or A2K3 by delivering an A2K file
format. That is exactly what I do as well. I have copies of the two newer
versions so I can be familair with them and so I can test in them, but I never
produce files in any format besides 97 and 2K since the latter also supports the
newer versions of Access
> > . . . If you do
> > that then the fact that a newer version uses a file format that is
> > not compatible with all of your users is not a problem. You
> > simply don't develop in that version except to create apps for
> > users who also have that version (or a compatible version).
>
> I see no reason whatsoever to use the A2K2 or A2K3 file formats. Why
> restrict your deployment platform for such a paltry collection of
> new features?
See above. I would never use the newer file format unless there were an
application requirement that necessitated that.
> > If you want to immediately acquire the latest version when it
> > comes out and learn all of the ins and outs that is commendable.
> > It doesn't necessarily follow that the newest release should
> > become the development platform for all of your users.
This was my main point. The OP seeemed to be conveying the idea that his move
to the newest version was a given and that this presents a problem if his users
stay with an older one. My position is that this is not an issue unless the
developer is silly enough to make it one.
lylefair
had a thriving aluminum business. He showed me into a room he had
prepared in the early 80's, so that he could "computerize" his business
when he had time. There were ten new, never used original IBM PCs
sporting single sided 5.25 floppies and green on black CRTs, all
sitting on desks with steno chairs in front. When I explained that
these were worthless (maybe not to Antiques Road Show) he decided not
to pursue the app.
lylefair
Here is a sample connection string
Provider=SQLOLEDB.1;Persist Security Info=False;User
ID=whatever;Initial Catalog=DB666666;Data
Source=aserver.discountasp.net;Use Procedure for Prepare=1;Auto
Translate=True;Packet Size=4096;Workstation ID=FFDBA;Use Encryption for
Data=False;
This is a typical ADO connection string.
David W. Fenton
news:ic1jk15jhkbg1g22t...@4ax.com:
> On Sun, 09 Oct 2005 15:05:48 -0500, "David W. Fenton"
><dXXXf...@bway.net.invalid> wrote:
>
> ...
>>Well, if that's a Boolean AND, then I'm not a serious developer,
>>as I don't own any version of Access beyond 2000. I develop in
>>that where necessary and deploy on A2K2 or A2K3 where necessary.
>>My clients using something beyond A2K provide me Terminal Server
>>access to administer and test the apps on the versions they are
>>deploying under.
>
> Personally, I find A2K too flakey to work in. A2K2 is far more
> stable. I've been able to convince most of my clients to switch
> to A2K2 or A2K3.
Well, it seems to me that the problems in A2K are for the developer,
not for the users, so I see no reason to suggest that they upgrade
so that my job is easier.
> I develop almost exclusively in A2K2 now, and use the 2K2 file
> format to keep people from running it under A2K since I didn't
> test it in A2K, and there's a good chance that won't work.
I have clients who are running a mix of A2K and A2K3, so I must
develop for A2K.
Of course, I mostly don't even use the features added in A2K, since
I still think like an A97 programmer. I am at the point now where I
very seldom develop in A97 and convert to A2K for production use
because I just got tired of troubleshooting the things that were
broken by A2K that work just fine in A97.
But it has increased development time, since A2K is just not as easy
to use for me -- the VBE is something I fight against at all turns.
And I still don't understand the issues that arise from the VBE
thinking code is executing when it isn't. This happened to me today
while programming something. I hadn't executed any code, just typed
it, and I got a message that whatever I wanted to do had to halt the
running code. That's the kind of thing that makes me crazy, partly
because sometimes you can't do something and you get no message
providing a reason. And there's no clear indication that I can see
that the code is executing.
But I do work in it and it doesn't feel quite as unwieldy as it used
to.
David W. Fenton
news:1128900324.6...@g43g2000cwa.googlegroups.com:
> All my DAPS connect to MS-SQL dbs.
So, you want the SQL dbs running on the ISP's host, or you're going
to allow your ISP's IP address to connect through the firewall to
the SQL Server db?
Sounds to me like asking for trouble for two reasons:
1. you're introducing more points of administration, one of which is
not really under your control (the web host), AND
2. you're opening up security holes in your network where the SQL
Server is hosted, either by allowing everyone to connect on an open
SQL Server port, or by authorizing such access from the web host's
IP address, which could subject you to worms or other forms of
nefarious activity should that web host be compromised.
lylefair
machine. Any code, script, com etc that is to be run, is run on the
client machine, except in the rare situation where code is directed to
be run at server (and I can find no evidence that such is the case in
DAP files; how could there be when they will run directly from the
client machine without any web host or server be involved?). That is
why Access stores a copy of the DAP (htm file) on the local machine. It
can be run directly from the client machine. All the web site does is
provide a repository for this file.
So it is not the web site that connects to the SQL-Sevrer, it is the
client machine, the same way the client machine to a web-enabled MS-SQL
Server connects though Access, Enterprise Manager, the new Visual
Components, ADO, ODBC or whatever.
Thus DAPs are dangerous only in the information they show in their html
source, and that is everything except the password (we can have the
password too if we wish to). This is why I do not make my DAPs
available on a public site. They are available only on a site the
requires an NT or NT-like logon with UserName and Password. Can you
open http://terraware.ca/DAP/loan.htm?
This discussion reenforces my point that there is no reason for web
hosts to ban DAPs. These are htm files. They are not run from the host!
They are run from the client machine. Why would the host care?
Steve Jorgensen
<dXXXf...@bway.net.invalid> wrote:
>Steve Jorgensen <nos...@nospam.nospam> wrote in
>news:ic1jk15jhkbg1g22t...@4ax.com:
>
>> On Sun, 09 Oct 2005 15:05:48 -0500, "David W. Fenton"
>><dXXXf...@bway.net.invalid> wrote:
>>
>> ...
>>>Well, if that's a Boolean AND, then I'm not a serious developer,
>>>as I don't own any version of Access beyond 2000. I develop in
>>>that where necessary and deploy on A2K2 or A2K3 where necessary.
>>>My clients using something beyond A2K provide me Terminal Server
>>>access to administer and test the apps on the versions they are
>>>deploying under.
>>
>> Personally, I find A2K too flakey to work in. A2K2 is far more
>> stable. I've been able to convince most of my clients to switch
>> to A2K2 or A2K3.
>
>Well, it seems to me that the problems in A2K are for the developer,
>not for the users, so I see no reason to suggest that they upgrade
>so that my job is easier.
The problems that I fight with in A2K cost me time and my clients money, so
I'll tell them that and suggest they upgrade. If a client insists that it's
not convenient for them to upgrade from A2K, I don't argue, and I do the
development in A2K. If, however, the client agrees to go to A2K2/3, I do the
development in A2K2, and use the A2K2 file format to enforce the fact that the
code is supported in A2K.
...
>Of course, I mostly don't even use the features added in A2K, since
>I still think like an A97 programmer. I am at the point now where I
>very seldom develop in A97 and convert to A2K for production use
>because I just got tired of troubleshooting the things that were
>broken by A2K that work just fine in A97.
>
>But it has increased development time, since A2K is just not as easy
>to use for me -- the VBE is something I fight against at all turns.
>And I still don't understand the issues that arise from the VBE
>thinking code is executing when it isn't. This happened to me today
>while programming something. I hadn't executed any code, just typed
>it, and I got a message that whatever I wanted to do had to halt the
>running code. That's the kind of thing that makes me crazy, partly
>because sometimes you can't do something and you get no message
>providing a reason. And there's no clear indication that I can see
>that the code is executing.
As long as you use A2K2 now, you might as well start using some of the things
it can do that are nice and make up (completely or incompletely) for some of
the negative aspects of A2K and above.
For one thing, custom events are a great way to untangle some otherwise tricky
VBA coding problems, particularly circular dependency types of issues. It's
also nice to be able to create UDFs in class modules (including form modules)
and to define public enumerations in same class modules where the procedures
that use them reside instead of having to put them in a separate standard
module somewhere.
Here are 2 ways I've gotten benefit from using custom events:
1. A form could be opened form multiple places and a calling form may need to
refresh itself when something happens on the invoked form. Using an even
helps keep things nicely decoupled since the called form just raises an event
to say when the action occurred, and the calling form decides what action to
take as a result. The invoked form doesn't need to know what will be
receiving the event or what it will do with it.
2. Since in VBA, a circular reference is a memory leak waiting to happen, how
does, for instance, one item in a linked list pass information to the thing
that links to it? A bidirectionally linked list is a circular reference, so
that's not the best idea. Using an event, the referenced object can make
calls to the item that refers to it.
>But I do work in it and it doesn't feel quite as unwieldy as it used
>to.
Part of it is just the devil you know vs the devil you don't know. At one of
my client sites, I get to work with 2 monitors - that's when the separate VBE
window really starts to seem like a good thing.
Danny J. Lesandrini
>> Personally, I find A2K too flakey to work in. A2K2 is far more
>> stable. I've been able to convince most of my clients to switch
>> to A2K2 or A2K3.
>
> Well, it seems to me that the problems in A2K are for the developer,
> not for the users, so I see no reason to suggest that they upgrade
> so that my job is easier.
>
Isn't A2K more prone to corruption? I could be wrong about this,
but that's what I recall from past posts ... and what I've personally
experienced.
The problem I'm speaking of occurs when people with A2002 or
A2003 attach to a back end A2000 that is also being edited by
someone with A2000. Some offices buy new computers with whatever
version of Office comes with it and have mixed environments. This
seems to cause the corruption ... rather suggesting that they should
upgrade to something newer ... A2002 at least and A2003 is better,
in this scenario of mixed version use.
Br@dley
> On Sun, 09 Oct 2005 19:29:22 -0500, "David W. Fenton"
<>
> At one of my client sites, I get to work with 2 monitors - that's
> when the separate VBE window really starts to seem like a good thing.
Duel screen is very handy for a developer... I use it all the time. It's
good to be able to see the live form while you're stepping through code.
--
regards,
Bradley
A Christian Response
http://www.pastornet.net.au/response
David W. Fenton
> For one thing, custom events are a great way to untangle some
> otherwise tricky VBA coding problems, particularly circular
> dependency types of issues. It's also nice to be able to create
> UDFs in class modules (including form modules) and to define
> public enumerations in same class modules where the procedures
> that use them reside instead of having to put them in a separate
> standard module somewhere.
Those are not things that I need, Steve, because I don't introduce
the kind of convolution into my applications that seems to come
naturally for you.
Steve, I really think you're programming in the wrong environment.
Larry often gives his little canned response about using Access for
what Access is good for and not expecting it to be something it's
not, and I'm in his camp. You seem to me to want Access to be
something it's not, and because of that, end up with complexities in
your code that just never happen in my own.
[]
>>But I do work in it and it doesn't feel quite as unwieldy as it
>>used to.
>
> Part of it is just the devil you know vs the devil you don't know.
> At one of my client sites, I get to work with 2 monitors - that's
> when the separate VBE window really starts to seem like a good
> thing.
The two windows are not the problem. Well, actually, yes it is, as
it necessitates the inclusion of a browser to get from one code
module to another, and that's a problem, as it is badly organized
(from my point of view). The main issue for me is the fact that I
can no longer know when the code is running and what the
interactions are. There's also the risk of losing changes because of
the stupid way the VBA handles unsaved code. I just compile and save
before leaving the VBE window so I never lose changes, but it's a
danger that's not there in the old way of doing things.
I'm completely familiar and comfortable with the A2K+ VBE. I just
don't like it, and I don't think I ever will.
Steve Jorgensen
<dXXXf...@bway.net.invalid> wrote:
>Steve Jorgensen <nos...@nospam.nospam> wrote in
>news:p1hjk11hn7a4aaalg...@4ax.com:
>
>> For one thing, custom events are a great way to untangle some
>> otherwise tricky VBA coding problems, particularly circular
>> dependency types of issues. It's also nice to be able to create
>> UDFs in class modules (including form modules) and to define
Sorry - that should read UDTs
>> public enumerations in same class modules where the procedures
>> that use them reside instead of having to put them in a separate
>> standard module somewhere.
>
>Those are not things that I need, Steve, because I don't introduce
>the kind of convolution into my applications that seems to come
>naturally for you.
I will agree that I still battle with a tendency to make things more complex
than necessary, but I disagree with the idea that these things are not
mindbogglingly useful in many common circumstances.
>Steve, I really think you're programming in the wrong environment.
>Larry often gives his little canned response about using Access for
>what Access is good for and not expecting it to be something it's
>not, and I'm in his camp. You seem to me to want Access to be
>something it's not, and because of that, end up with complexities in
>your code that just never happen in my own.
I also disagree with that on 2 fronts.
1. The implication that simple applications don't have problems like
pathalogical coupling of design components that can be helped by things like
custom events.
2. The idea that there are not many valid reasons to solve complex programming
problems in Access VBA.
Details on #1:
Almost every application I work on that was designed by another sub-expert
Access programmer has some variation on the form that can be opened from
several places, and needs to talk back to those other places. Usually, the
awful mess I find is that the second form has intimate knowledge about the
structure and function of all those other things and some kind of case
selection to figure out which of them applies. This is also out of date in
pretty much -every- case because changes were made to one or more of the other
forms without accounting for the consequences.
I have untangled many of these using custom events. The dependent form raises
an event, and the depending form receives the event if it's listening, and
does the right thing. The code that relates to the details of each form is
only in that form - where it belongs.
Regarding the creation of public enumerations in class modules (forms and
reports are also class modules), I wish everyone would do more of that.
Without them, people keep doing things like abusing Boolean to represent a
selection between 2 alternatives, neither of which is really more "True" than
the other - then they get in more trouble when option 3 comes along.
Details on #2:
A large fraction of the applications I've written have evolved to reach or
exceed the border at which, if the app were to be rewritten, Access might not
be the best choice. In most of these cases, the business priorities made it
better at that point to keep doing battle with the Access application rather
than rewriting it based on currently known requirements. In these cases, more
and more of the application becomes code-driven, though it remains in Access.
Regardless of the evolution factor, many applications have multiple facets,
most of which are simple, and a few of which are complex. In those cases, we
have to choose whether to do the easy stuff the hard way, or the easy stuff
the easy way (MS Access) and the hard stuff either in an imperfect platform
(Access VBA) or in a separate platform, and link the code together. In many
of these cases, simplicity of deployment leans heavily toward doing the
complex stuff in VBA, even though there may be much better-matched tools, and
using all known VBA tricks and patterns to keep the code manageable
nonetheless.
>
>[]
>
>>>But I do work in it and it doesn't feel quite as unwieldy as it
>>>used to.
>>
>> Part of it is just the devil you know vs the devil you don't know.
>> At one of my client sites, I get to work with 2 monitors - that's
>> when the separate VBE window really starts to seem like a good
>> thing.
>
>The two windows are not the problem. Well, actually, yes it is, as
>it necessitates the inclusion of a browser to get from one code
>module to another, and that's a problem, as it is badly organized
>(from my point of view). The main issue for me is the fact that I
>can no longer know when the code is running and what the
>interactions are. There's also the risk of losing changes because of
>the stupid way the VBA handles unsaved code. I just compile and save
>before leaving the VBE window so I never lose changes, but it's a
>danger that's not there in the old way of doing things.
>
>I'm completely familiar and comfortable with the A2K+ VBE. I just
>don't like it, and I don't think I ever will.
I'm not at all saying the problems aren't there or don't matter, just to at
least look for the few things that got better since we have to work in it
anyway. Regarding the save problem, I've finally developed the habit of
saving every few minutes. That's not a good thing to have to do, but it has
been working for me.
David W. Fenton
> On Mon, 10 Oct 2005 13:56:41 -0500, "David W. Fenton"
><dXXXf...@bway.net.invalid> wrote:
[]
> I also disagree with that on 2 fronts.
>
> 1. The implication that simple applications don't have problems
> like pathalogical coupling of design components that can be helped
> by things like custom events.
>
> 2. The idea that there are not many valid reasons to solve complex
> programming problems in Access VBA.
>
>
> Details on #1:
>
> Almost every application I work on that was designed by another
> sub-expert Access programmer has some variation on the form that
> can be opened from several places, and needs to talk back to those
> other places. Usually, the awful mess I find is that the second
> form has intimate knowledge about the structure and function of
> all those other things and some kind of case selection to figure
> out which of them applies. This is also out of date in pretty
> much -every- case because changes were made to one or more of the
> other forms without accounting for the consequences.
This is why I wrap such forms in a class module, and all the
different locations communicated with the class module which then
takes care of communicating with the target form. With a single
intermediary between all strating contexts and the target form, it's
simple.
And I don't need to raise any events to do that.
[]
> Regarding the creation of public enumerations in class modules
> (forms and reports are also class modules), I wish everyone would
> do more of that. Without them, people keep doing things like
> abusing Boolean to represent a selection between 2 alternatives,
> neither of which is really more "True" than the other - then they
> get in more trouble when option 3 comes along.
It seems crazy to me to need to depend on an ENUM to prevent a
stupid programming error like that.
I don't use ENUMS (I don't program in any version of Access that
supports it) and I don't mis-choose the data types for my
parameters.
This is really just a matter of parameter checking in the
subroutine. Yes, and ENUM is an easy way to do that, but it can be
done without it, too.
Tell me this, since I don't use them: does an ENUM prohibit the
passing of an invalid value, or does it just populate the
Intellisense dropdown? If only the latter, it's really not of much
use at all, as it doesn't prevent the error from being coded, it
just provides more help to the programmer, should she choose to
avail herself of it.
If the subroutine is written right, the internal value checking for
the parameters that have a limited number of correct values will
prevent the incorrect values and will handle them, too. Does an ENUM
provide that feedback, too?
I just don't see that there's anything automatically superior about
an ENUM structure that can't bee done nearly as easily (though
without the minor benefit of Intellisense) with traditional proper
coding inside the black box.
[]
> Regardless of the evolution factor, many applications have
> multiple facets, most of which are simple, and a few of which are
> complex. In those cases, we have to choose whether to do the easy
> stuff the hard way, or the easy stuff the easy way (MS Access) and
> the hard stuff either in an imperfect platform (Access VBA) or in
> a separate platform, and link the code together. In many of these
> cases, simplicity of deployment leans heavily toward doing the
> complex stuff in VBA, even though there may be much better-matched
> tools, and using all known VBA tricks and patterns to keep the
> code manageable nonetheless.
Perhaps I overestimate my experience, but I think I've done some
pretty complex apps in Access, and I've never needed these two
things you seem to think are so crucial.
Perhaps I'm just an amateur, and if so, I'm glad, since I don't have
the headaches that you seem to generate for yourself.
[]
>>I'm completely familiar and comfortable with the A2K+ VBE. I just
>>don't like it, and I don't think I ever will.
>
> I'm not at all saying the problems aren't there or don't matter,
> just to at least look for the few things that got better since we
> have to work in it anyway. Regarding the save problem, I've
> finally developed the habit of saving every few minutes. That's
> not a good thing to have to do, but it has been working for me.
I hit compile to make sure I've not made any errors and immediately
save. It's just automatic.
But that's a case where the inadequacies of the IDE have trained us
to work around the inadequacies. Yes, it's doable, but it's *not* a
good thing at all. It's a degradation of capability, which is what
has bothered me about the VBE from the beginning -- it seems to me
that suitability of the existing IDE to Access was sacrificed for a
faux compatibility with other applications where code was far, far
less important, and for which there was simply no overlap in the
direction that would be helpful to those only familiar with the VBE.
In other words, we Access developers sacrificed suitability of our
existing IDE for compatibility that wasn't goibg to help even one of
us do our jobs more easily. And I doubt that a familiar IDE would
bridge the gap sufficiently to truly allow someone accustomed to
coding in Word or Excel to start coding in Access -- the stumbling
blocks of the different IDE are minuscule in comparison to the
knowledge of databases required, along with the completely different
object models.
Microsoft could have given us a separete code window without forcing
the inadequate VBE down our throats.
And don't get me started on OPTION EXPLICIT.
Idiots, idiots, idiots.
But, of course, I have no strong opinions on the subject. . .
Steve Jorgensen
<dXXXf...@bway.net.invalid> wrote:
Are we talking about the same problem? I'm referring to when the form needs
to inform its invoker that something has happened. If you wrap the form in a
class module, all you've done is move all that coupling into a wrapper.
>> Regarding the creation of public enumerations in class modules
>> (forms and reports are also class modules), I wish everyone would
>> do more of that. Without them, people keep doing things like
>> abusing Boolean to represent a selection between 2 alternatives,
>> neither of which is really more "True" than the other - then they
>> get in more trouble when option 3 comes along.
>
>It seems crazy to me to need to depend on an ENUM to prevent a
>stupid programming error like that.
>
>I don't use ENUMS (I don't program in any version of Access that
>supports it) and I don't mis-choose the data types for my
>parameters.
When I'm saying enums, I could just as well be saying constants (though the
auto-sense with enums is nice), it's just that enums are the only kind of
constant that can be defined publicly in -any- version of VBA, so that's why I
mention them so favorably. I also try to write code such that enums are not
required, but VBA lacks the OOP features I would usually use as alternatives,
so I end up using enums medium-often.
>This is really just a matter of parameter checking in the
>subroutine. Yes, and ENUM is an easy way to do that, but it can be
>done without it, too.
It's a matter of avoiding magic values in the code. If a value has a special
meaning, give it a name, and best if the compiler can validate that the name
was typed correctly.
>Tell me this, since I don't use them: does an ENUM prohibit the
>passing of an invalid value, or does it just populate the
>Intellisense dropdown? If only the latter, it's really not of much
>use at all, as it doesn't prevent the error from being coded, it
>just provides more help to the programmer, should she choose to
>avail herself of it.
As you know, constants and enums do nothing to prevent passing a wrong value
as a raw value, but if you use the names, you get the right values. When you
read the code, you can also see what the value is suposed to mean rather than
that it happens to equal 4.
>If the subroutine is written right, the internal value checking for
>the parameters that have a limited number of correct values will
>prevent the incorrect values and will handle them, too. Does an ENUM
>provide that feedback, too?
Obviously - no. That's not the problem enums solve.
>I just don't see that there's anything automatically superior about
>an ENUM structure that can't bee done nearly as easily (though
>without the minor benefit of Intellisense) with traditional proper
>coding inside the black box.
An axample would be helpful.
>> Regardless of the evolution factor, many applications have
>> multiple facets, most of which are simple, and a few of which are
>> complex. In those cases, we have to choose whether to do the easy
>> stuff the hard way, or the easy stuff the easy way (MS Access) and
>> the hard stuff either in an imperfect platform (Access VBA) or in
>> a separate platform, and link the code together. In many of these
>> cases, simplicity of deployment leans heavily toward doing the
>> complex stuff in VBA, even though there may be much better-matched
>> tools, and using all known VBA tricks and patterns to keep the
>> code manageable nonetheless.
>
>Perhaps I overestimate my experience, but I think I've done some
>pretty complex apps in Access, and I've never needed these two
>things you seem to think are so crucial.
In case you're wondering - I have no questions regarding your experience, and
I also assume your code is excellent in most every way, and better than mine
in many ways, even if it's not a lot like mine. It's also necessarily a
matter of "need", but rather a question of whether some tools provide for code
that's dramatically simpler and/or easier to maintain in some cases, or at
least requiring less time and cleverness to come up with designs that are
sufficiently simple and maintainable.
>Perhaps I'm just an amateur, and if so, I'm glad, since I don't have
>the headaches that you seem to generate for yourself.
Perhaps you think I don't seem to value your opinions - I do. In fact, if you
can tell me some ways to think about problems that can use fewer new, fancy
features to create very well-engineered applications, I'm anxious to know
them. Although I tend to overengineer, I do not -value- overengineering, and
I don't try to use more features just to be clever. I value keeping things as
simple as possible (but no simpler).
>>>I'm completely familiar and comfortable with the A2K+ VBE. I just
>>>don't like it, and I don't think I ever will.
>>
>> I'm not at all saying the problems aren't there or don't matter,
>> just to at least look for the few things that got better since we
>> have to work in it anyway. Regarding the save problem, I've
>> finally developed the habit of saving every few minutes. That's
>> not a good thing to have to do, but it has been working for me.
>
>I hit compile to make sure I've not made any errors and immediately
>save. It's just automatic.
Someone once told me they had fewer project corruptions if they always save
before compile. I don't know if it's true or not, but - chicken soup - I
always do it that way now.
>But that's a case where the inadequacies of the IDE have trained us
>to work around the inadequacies. Yes, it's doable, but it's *not* a
>good thing at all. It's a degradation of capability, which is what
Didn't I just say I agree that's not a good thing?
>has bothered me about the VBE from the beginning -- it seems to me
>that suitability of the existing IDE to Access was sacrificed for a
>faux compatibility with other applications where code was far, far
>less important, and for which there was simply no overlap in the
>direction that would be helpful to those only familiar with the VBE.
I'm sure that's true, but I'm also sure there has been removal of code
duplication between Access VBA and standard VBA that has helped MS meet
release deadlines, keep from fixing the same bugs in multiple code bases, etc.
I have no where near enough information to say whether MS made the right
decision, but it's certainly plausible that what they did was the lesser of
evils.
>In other words, we Access developers sacrificed suitability of our
>existing IDE for compatibility that wasn't goibg to help even one of
>us do our jobs more easily. And I doubt that a familiar IDE would
>bridge the gap sufficiently to truly allow someone accustomed to
>coding in Word or Excel to start coding in Access -- the stumbling
>blocks of the different IDE are minuscule in comparison to the
>knowledge of databases required, along with the completely different
>object models.
Nothing to argue with there - and remember I'm not arguing that the new IDE is
on-balance, better for Access.
>And don't get me started on OPTION EXPLICIT.
or me either.
>Idiots, idiots, idiots.
>
>But, of course, I have no strong opinions on the subject. . .
<g>
teddy...@hotmail.com
Steve Jorgensen wrote:
[...]
> When I'm saying enums, I could just as well be saying constants (though the
> auto-sense with enums is nice), it's just that enums are the only kind of
> constant that can be defined publicly in -any- version of VBA
I *must* have misunderstood you. Surely you can just write in any code
module
Public Const gcintMyConstant As Integer = 2
Edward
Steve Jorgensen
I was incomplete - that should read "... defined publicly in a class module in
-any- version of VBA."
David W. Fenton
> On Mon, 10 Oct 2005 22:50:26 -0500, "David W. Fenton"
><dXXXf...@bway.net.invalid> wrote:
>
>>Steve Jorgensen <nos...@nospam.nospam> wrote in
>>news:gubmk1hv8bfst7lcu...@4ax.com:
[]
>>> Details on #1:
>>>
>>> Almost every application I work on that was designed by another
>>> sub-expert Access programmer has some variation on the form that
>>> can be opened from several places, and needs to talk back to
>>> those other places. Usually, the awful mess I find is that the
>>> second form has intimate knowledge about the structure and
>>> function of all those other things and some kind of case
>>> selection to figure out which of them applies. This is also out
>>> of date in pretty much -every- case because changes were made to
>>> one or more of the other forms without accounting for the
>>> consequences.
>>
>>This is why I wrap such forms in a class module, and all the
>>different locations communicated with the class module which then
>>takes care of communicating with the target form. With a single
>>intermediary between all strating contexts and the target form,
>>it's simple.
>>
>>And I don't need to raise any events to do that.
>
> Are we talking about the same problem? I'm referring to when the
> form needs to inform its invoker that something has happened. If
> you wrap the form in a class module, all you've done is move all
> that coupling into a wrapper.
Well, I can't conceive of a situation where the form needs to inform
the invoker that it wouldn't be a piece of cake to have the class
module doing the informing. Indeed, I'm having a hard time
conceiving of a situation that meets your requirements that is not a
design error in the first place. All the situations that would be
appropriate seem to me to be easy enough to handle through a class
module wrapper what would know it needs to do something to the
invoking form when certain of its properties have been changed from
the invoked form.
>>> Regarding the creation of public enumerations in class modules
>>> (forms and reports are also class modules), I wish everyone
>>> would do more of that. Without them, people keep doing things
>>> like abusing Boolean to represent a selection between 2
>>> alternatives, neither of which is really more "True" than the
>>> other - then they get in more trouble when option 3 comes along.
>>
>>It seems crazy to me to need to depend on an ENUM to prevent a
>>stupid programming error like that.
>>
>>I don't use ENUMS (I don't program in any version of Access that
>>supports it) and I don't mis-choose the data types for my
>>parameters.
>
> When I'm saying enums, I could just as well be saying constants
> (though the auto-sense with enums is nice), it's just that enums
> are the only kind of constant that can be defined publicly in
> -any- version of VBA, . . .
Well, after a certain version of VBA, which I don't use. . .
> . . . so that's why I mention them so favorably.
> I also try to write code such that enums are not required, but VBA
> lacks the OOP features I would usually use as alternatives, so I
> end up using enums medium-often.
If I had them, I'd use them, the same way I use the narrowest
possible data types in declaring variables. But not having them is
no more hardship than was lacking a dedicated Boolean data type in
Access 2's Access Basic. Indeed, lacking ENUMS requires
significantly less working around to verify parameters, because the
code to verify is not much more typing than the definition of the
ENUM itself.
>>This is really just a matter of parameter checking in the
>>subroutine. Yes, and ENUM is an easy way to do that, but it can be
>>done without it, too.
>
> It's a matter of avoiding magic values in the code. If a value
> has a special meaning, give it a name, and best if the compiler
> can validate that the name was typed correctly.
I can't see how that's much different than using named constants,
except for the fact that it's a structure designed to make it much
clearer what it applies to, but there are ways to manage that in
organizing and commenting your modules. No, it's not as closely tied
in for the compiler, but it still gets the job done.
>>Tell me this, since I don't use them: does an ENUM prohibit the
>>passing of an invalid value, or does it just populate the
>>Intellisense dropdown? If only the latter, it's really not of much
>>use at all, as it doesn't prevent the error from being coded, it
>>just provides more help to the programmer, should she choose to
>>avail herself of it.
>
> As you know, constants and enums do nothing to prevent passing a
> wrong value as a raw value, but if you use the names, you get the
> right values. When you read the code, you can also see what the
> value is suposed to mean rather than that it happens to equal 4.
So, it's just a fancy way of organizing constants, as I thought.
Of course I can see the utility, and if I had it available I'd use
it. But it's hardly sufficient reason to switch versions of Access
from the widely compatible A2K format to A2K2 or above, in my
opinion.
>>If the subroutine is written right, the internal value checking
>>for the parameters that have a limited number of correct values
>>will prevent the incorrect values and will handle them, too. Does
>>an ENUM provide that feedback, too?
>
> Obviously - no. That's not the problem enums solve.
>
>>I just don't see that there's anything automatically superior
>>about an ENUM structure that can't bee done nearly as easily
>>(though without the minor benefit of Intellisense) with
>>traditional proper coding inside the black box.
>
> An axample would be helpful.
From me? I don't use ENUMS so I can't give you code that uses them
and is equivalent to code that doesn't.
This is your case, not mine, and I think you could give an example
to convince us why it's so useful as to partly justify using a less
compatible file format.
[]
>>has bothered me about the VBE from the beginning -- it seems to me
>>that suitability of the existing IDE to Access was sacrificed for
>>a faux compatibility with other applications where code was far,
>>far less important, and for which there was simply no overlap in
>>the direction that would be helpful to those only familiar with
>>the VBE.
>
> I'm sure that's true, but I'm also sure there has been removal of
> code duplication between Access VBA and standard VBA that has
> helped MS meet release deadlines, keep from fixing the same bugs
> in multiple code bases, etc. I have no where near enough
> information to say whether MS made the right decision, but it's
> certainly plausible that what they did was the lesser of evils.
The argument here is for having a single codebase for your IDE, not
having an identical IDE in all programs. Those are two completely
different things.
Also, the Access IDE could have been the one that won, rather than
the dumbed-down one.
The argument from code management is neutral on those points, so
really is not in favor of the introduction of the VBE into Access at
all.
Steve Jorgensen
<dXXXf...@bway.net.invalid> wrote:
...
>> When I'm saying enums, I could just as well be saying constants
>> (though the auto-sense with enums is nice), it's just that enums
>> are the only kind of constant that can be defined publicly in
>> -any- version of VBA, . . .
>
>Well, after a certain version of VBA, which I don't use. . .
>
>> . . . so that's why I mention them so favorably.
>> I also try to write code such that enums are not required, but VBA
>> lacks the OOP features I would usually use as alternatives, so I
>> end up using enums medium-often.
>
>If I had them, I'd use them, the same way I use the narrowest
>possible data types in declaring variables. But not having them is
>no more hardship than was lacking a dedicated Boolean data type in
>Access 2's Access Basic. Indeed, lacking ENUMS requires
>significantly less working around to verify parameters, because the
>code to verify is not much more typing than the definition of the
>ENUM itself.
It seems like either I'm not communicating or you're refusing to read what I'm
saying. I am -not- trying to say there's anything extraordinarily superior
about the concept of enums vs the concept of regular contants.
What I -am- saying is that in Access VBA prior to A2K there was no way to
declare -any- kind of public constant in a class module, be it a form's
module, a report's module, or a stand-alone class. In A2K and newer, we can
declare public enums in a class which is a way way of declaring public
constants in a class module.
Did I now communicate what I'm trying to get across?
Being able to define the constants in the same module as the procedures that
expect them keeps the definitions (and associated comments) close to the rest
of the closely related code, keeps the proliferation of support modules down,
and prevents having to copy a support module to another project along with the
object in order to make it compile.
Steve Jorgensen
<dXXXf...@bway.net.invalid> wrote:
...
>> Are we talking about the same problem? I'm referring to when the
>> form needs to inform its invoker that something has happened. If
>> you wrap the form in a class module, all you've done is move all
>> that coupling into a wrapper.
>
>Well, I can't conceive of a situation where the form needs to inform
>the invoker that it wouldn't be a piece of cake to have the class
>module doing the informing. Indeed, I'm having a hard time
>conceiving of a situation that meets your requirements that is not a
>design error in the first place. All the situations that would be
>appropriate seem to me to be easy enough to handle through a class
>module wrapper what would know it needs to do something to the
>invoking form when certain of its properties have been changed from
>the invoked form.
Can't coceive of it? I see code like that in almost every application I work
on - particularly in modeless applications.
A really common example is a multi-record view with a separate modeless form
for adding records. After adding the new record, the list form should be
requeried to display the new record, and possibly move to the new record.
What I often see in this case is that the new record form directly requeries
the calling form, and seeks to the new record. Often, this code is broken
because it fails to check whether the original form is still open, fails to be
updated when the name or structure of the calling form has been changed, or
fails to account for other places that it could be opened from. If it does
account for multiple places it could be called from, it gets even more messy.
I don't see how wrapping that in a class does anything but move the mess to
the wrapper class.
Now - I will grant you that it's often worth sticking with a modelal design,
so you can use dialog forms and forget that whole issue and I often do, but
sometimes there is a requirement for modeless.
When I run across this kind of pathological coupling, I find event procedures
to be an easy way to clean it up. In the case I described above, the new
record form jsut raises an event when the new record has been added. If the
invoking form is holding a WithEvents reference to it, it can receive that
event and decide what it wants to do about it. If nothing's listening,
nothing happens - perfect.
>>>has bothered me about the VBE from the beginning -- it seems to me
>>>that suitability of the existing IDE to Access was sacrificed for
>>>a faux compatibility with other applications where code was far,
>>>far less important, and for which there was simply no overlap in
>>>the direction that would be helpful to those only familiar with
>>>the VBE.
>>
>> I'm sure that's true, but I'm also sure there has been removal of
>> code duplication between Access VBA and standard VBA that has
>> helped MS meet release deadlines, keep from fixing the same bugs
>> in multiple code bases, etc. I have no where near enough
>> information to say whether MS made the right decision, but it's
>> certainly plausible that what they did was the lesser of evils.
>
>The argument here is for having a single codebase for your IDE, not
>having an identical IDE in all programs. Those are two completely
>different things.
>
>Also, the Access IDE could have been the one that won, rather than
>the dumbed-down one.
Again, I'm not saying if MS was right or wrong - I wasn't there, and I don't
know the code internals. It just seems plausible to me that the road MS chose
was the only viable one. Were they going to try to duplicate the JET storage
for module objects in Word documents? Were they going to change all the other
office apps to be able to open modules in the application's MDI client window?
This is all still a bit rarified from my original point as well, which was not
that I like MS' choice, but that since we have to live with it, let's at least
explore the few new gool goodies that we got with it.
>The argument from code management is neutral on those points, so
>really is not in favor of the introduction of the VBE into Access at
>all.
You can't know it was neutral anymore than I can know if it was not - we're
both speculating. This is unknowable to us unless we were to become
programmers or architects on the MS Office internal code base.
David W. Fenton
Well, I now understand that you're limiting your comments to class
modules, but I'm completely underwhelmed about why it matters. Yes,
it's messy to have to put the public constants for your class module
somewhere else, but no messier than any other global constants that
may or may not be declared in the same module as they are used.
> Being able to define the constants in the same module as the
> procedures that expect them keeps the definitions (and associated
> comments) close to the rest of the closely related code, . . .
Which is very desirable and helpful, but hardly something that is a
deal-breaker in regard to writing good code.
> . . . keeps the
> proliferation of support modules down, . . .
Again, desirable, but you could easily have a module dedicated to
the purpose of storing public constants for your class modules, with
appropriate comments. So, the proliferation of modules would be
pretty minimal.
> . . . and prevents having to copy
> a support module to another project along with the object in order
> to make it compile.
Well, now, that's a *different* issue. I'm not sure I think it's
wise to have public constants used internally in the class module as
well as by code calling the class module, but perhaps the reason I
wouldn't do it is because I can't.
Hmm. I have to meditate on that one.
I guess it does make sense, since you have to do validity checking
on the input values, and using the declared constants is a good way
to do it.
So, yes, I guess that is an advantage, but, hell, I'm constantly
copying the minimal amount of code from my libraries into new
applications, and I just attempt a compile until I've gotten all the
dependecies removed. That doesn't sound like a huge set of problems
to me, though I certainly agree that this is yet another thing that
would be nice, but still doesn't come close, in my opinion, to
justifying settling on a non-backwardly-compatible Access version.
It's another feature I'd use if I had it, but there are insufficient
such features for me to consider switching format.
David W. Fenton
> On Tue, 11 Oct 2005 19:22:39 GMT, "David W. Fenton"
><dXXXf...@bway.net.invalid> wrote:
>
> ...
>>> Are we talking about the same problem? I'm referring to when
>>> the form needs to inform its invoker that something has
>>> happened. If you wrap the form in a class module, all you've
>>> done is move all that coupling into a wrapper.
>>
>>Well, I can't conceive of a situation where the form needs to
>>inform the invoker that it wouldn't be a piece of cake to have the
>>class module doing the informing. Indeed, I'm having a hard time
>>conceiving of a situation that meets your requirements that is not
>>a design error in the first place. All the situations that would
>>be appropriate seem to me to be easy enough to handle through a
>>class module wrapper what would know it needs to do something to
>>the invoking form when certain of its properties have been changed
>>from the invoked form.
>
> Can't coceive of it? I see code like that in almost every
> application I work on - particularly in modeless applications.
>
> A really common example is a multi-record view with a separate
> modeless form for adding records. . . .
Well, a modeless form for adding records is a design error to me, as
you should be required to complete or abandon the new record before
continuing to another context.
> . . . After adding the new record,
> the list form should be requeried to display the new record, and
> possibly move to the new record.
Even with a modeless new record form (which I think is a completely
mistaken approach -- too easy for the user to accidentally bring
another form to the foreground and then forget that there's a partly
completely record sitting there in the background), I see no reason
why a class module couldn't be used for taking care of
communication. Assuming, for instance, that you can add records a
particular table in many different contexts, and you want to requery
the context from which the add was initiated. Using the class module
as your intermediary, you set up the class in the ADD command button
(recording the calling context and what needs to be requeried), and
the class opens the add record form. When the Add form is closed, it
tells the class that it's closed which then requeries the
appropriate forms, and then it destroys the class instance it was
using.
> What I often see in this case is that the new record form directly
> requeries the calling form, and seeks to the new record. Often,
> this code is broken because it fails to check whether the original
> form is still open, fails to be updated when the name or structure
> of the calling form has been changed, or fails to account for
> other places that it could be opened from. If it does account for
> multiple places it could be called from, it gets even more messy.
> I don't see how wrapping that in a class does anything but move
> the mess to the wrapper class.
It's not a mess if you write the wrapper class correctly. This is
exactly the kind of coding I do all the time for just this kind of
situation (though I would never do a record add in a modeless form).
> Now - I will grant you that it's often worth sticking with a
> modelal design, so you can use dialog forms and forget that whole
> issue and I often do, but sometimes there is a requirement for
> modeless.
You're going to have to come up with a different situation than
adding a new record modelessly because I consider that a design
error, because it's too important an operation, and too easy for it
to get lost if it's done modelessly.
> When I run across this kind of pathological coupling, I find event
> procedures to be an easy way to clean it up. In the case I
> described above, the new record form jsut raises an event when the
> new record has been added. If the invoking form is holding a
> WithEvents reference to it, it can receive that event and decide
> what it wants to do about it. If nothing's listening, nothing
> happens - perfect.
I see absolutely no advantage to that over a properly constructed
class wrapper, which wouldn't be spaghetti code at all -- all you'd
need in the class is an array of form references that you'd walk
through and requery, and appropriate property LETs for adding to
that array, and appropriate methods when completing the record
addition.
>>>>has bothered me about the VBE from the beginning -- it seems to
>>>>me that suitability of the existing IDE to Access was sacrificed
>>>>for a faux compatibility with other applications where code was
>>>>far, far less important, and for which there was simply no
>>>>overlap in the direction that would be helpful to those only
>>>>familiar with the VBE.
>>>
>>> I'm sure that's true, but I'm also sure there has been removal
>>> of code duplication between Access VBA and standard VBA that has
>>> helped MS meet release deadlines, keep from fixing the same bugs
>>> in multiple code bases, etc. I have no where near enough
>>> information to say whether MS made the right decision, but it's
>>> certainly plausible that what they did was the lesser of evils.
>>
>>The argument here is for having a single codebase for your IDE,
>>not having an identical IDE in all programs. Those are two
>>completely different things.
>>
>>Also, the Access IDE could have been the one that won, rather than
>>the dumbed-down one.
>
> Again, I'm not saying if MS was right or wrong - I wasn't there,
> and I don't know the code internals. It just seems plausible to
> me that the road MS chose was the only viable one. Were they
> going to try to duplicate the JET storage for module objects in
> Word documents? Were they going to change all the other office
> apps to be able to open modules in the application's MDI client
> window?
You seem to me to be confusing the UI structure with the storage
structure. That can be taken care of with some kind of abstraction
layer between the UI and the host application. Clearly, the VBE
already works that way, since Word and Excel don't store their
modules in the same place or format as Access does.
> This is all still a bit rarified from my original point as well,
> which was not that I like MS' choice, but that since we have to
> live with it, let's at least explore the few new gool goodies that
> we got with it.
I don't see where that would be your point. I find A2K+ harder to
use because of the VBE. This makes me less productive.
>>The argument from code management is neutral on those points, so
>>really is not in favor of the introduction of the VBE into Access
>>at all.
>
> You can't know it was neutral anymore than I can know if it was
> not - we're both speculating. This is unknowable to us unless we
> were to become programmers or architects on the MS Office internal
> code base.
Sure, of course it's neutral. Since there's already an abstraction
interface in between the VBE and the host application, the question
is simply a matter of the design of the abstraction layer, and each
host application has a different one anyway. From that point of
view, the VBE is just a "skin" and Microsoft chose the non-Access
"skin" for all the programs. The very acting of choosing a single
"skin" is what gets you the code manageability -- you still have to
maintain the abstraction interface that mediates between the VBE and
the host applications.
BTW, I was googling something completely unrelated and saw that we
already had this discussion in May 2004. I didn't recall it at all,
but we went through exactly the same set of issues in regard to the
VBE.
I'll try to remember not to go on this rant again the next time it
comes up.
aaron...@gmail.com
all the action in the new version of ACCESS-- it has to do with ACCESS
DATA PROJECTS
it is a much more reliable backend for your data
i've just had too mcuh stability problems with a dozen users on Access
MDB
Steve Jorgensen
You're conflating 2 different issues, SQL Server back-end, and Access MDB
front-end. My first Access front end to SQL Server was an MDB, and in spite
of some difficult interfacing, the project went smoothly and was maintainable.
My first attempt to create an ADP was fater doing 3 successful conversions of
MDBs to MDB SQL Server front-ends, and it was a total fiasco. Almost every
hour I spent working on the ADP app was working around something that doesn't
work or doesn't work in the way it needs to. In many cases, things that
worked only worked until some seemingly innocuous change or some update to
MDAC occurred.
Add to that the fact that MS clearly -stopped- doing any useful work on ADP
functionality after Access 2002. None of the bugs that havve dogged em have
been addressed, and no new ADP features have been added. Presumably, MS
noticed that it was costing a lot to try to fix the bugs in the fundamentally
flakey ADP code that hardly anyone is trying to use.
I am still doing new C/S Access development using MDBs, not ADPs.
lylefair
Steve Jorgensen wrote:
Sadly, I agree; ADPs were a great idea; they seemed to be wonderful. I
was an enthusiastic supporter and contributed to the MS ADP newsgroup.
But as I worked with them more and more I became less and less
enthused. Yes, I found a solution for every problem (except security)
but often after many hours of work; too frequently the solution failed
after one day, or one week, or one month.
I still use ADPs as follows:
1 for trivial personal databases;
2 to mock up web applications and to create sprocs and other objects
for their use (but I'm finding Visual Web Developer is superior for
this);
3. as the base for the wizard creation of DAPs connecting to MS-SQL
dbs;
4. without any base connection to aything; binding forms and reports to
ADO recordsets (this is not so trivial); I think this could be a very
strong development environment for anyone who wants an application
which combines notions of "bound" (we do not bind the form to a
recordsource connected through the project connection, but connect it
to an pristine ado recordset) and unbound (the application itself has
no base connection so it shows no database objects in the db window.)
In this way the developer would assume all responsibilities for
security, be it using application roles, crypt functions or whatever.
And of course, one would not be bound to one db as one would not have a
base connection to anything; one could have local tables in MSDE and
remote tables in an MS-SQL server. Some day in my spare time I'll
pursue this (ha ha; if you buy that perhaps you would be interested in
buying a bridge?)
But if a client wanted a MAJOR ADP project I would try to dissuade that
person and move him/her to something else, depending on needs; I would
need some serious money up front and a clear agreement about who was
responsible for the idiosyncracies (and security of the db) of ADPs
(this would not be me) before I would agree; if you think this isn't
going to happen, I think you are right.
lylefair
the strengths of ADPs and listening patiently to those who have
experienced difficulties with them.
Perhaps, you could (EVEN) adopt a gentler style.
Bob Alston
> Perhaps, you could (EVEN) adopt a gentler style.
>
Now is that the pot calling the kettle black.... or what???
David W. Fenton
news:1129256956....@g14g2000cwa.googlegroups.com:
> Sadly, I agree; ADPs were a great idea; they seemed to be
> wonderful.
I don't see that ADPs were ever a great idea. The whole
justification for them seems to me to have been to avoid the icky
old Jet db engine. That so patently stupid an idea that I dismissed
ADPs on the front end, without ever needing to waste hours, days and
weeks trying to make them work.
How, exactly, were ADPs a good idea?
lylefair
always right and a complete expert on things he has never used, David.
Because there is no DISCUSSION possible. Upon making a point to such a
person, he will assuredly come up with another issue that supports his
point of view and so on and so on. If he has to, at the end he will
quote scripture: "Michka said ... ". Thanks, but no thanks.
David W. Fenton
news:1129322102....@g44g2000cwa.googlegroups.com:
You drank the Kool Aid.
I didn't.
I'm just pointing out that I was right in my original estimation
that ADPs were of very little value, based on my assessment of the
bogus reasons for *why* they were created in the first place.
You have been the longest-term promoter of ADPs, and now you're off
them, too. It's not my fault that you invested all that time in a
worthless pursuit.
You can call me Howard if I can call you Colin.
Steve Jorgensen
<dXXXf...@bway.net.invalid> wrote:
>"lylefair" <lylefa...@aim.com> wrote in
>news:1129256956....@g14g2000cwa.googlegroups.com:
>
>> Sadly, I agree; ADPs were a great idea; they seemed to be
>> wonderful.
>
>I don't see that ADPs were ever a great idea. The whole
A crappy implementation does not make a great idea into a bad one - it's just
crappy execution.
>justification for them seems to me to have been to avoid the icky
>old Jet db engine. That so patently stupid an idea that I dismissed
>ADPs on the front end, without ever needing to waste hours, days and
>weeks trying to make them work.
That might have been a motivation. What I personally wanted out of ADPs, and
why I tried to use them, was to have a more seemless environment for doing
development on applications that already had good a reason to be
client/server, not to start writing apps as C/S that I would not otherwise
have done that way.
For instance, in an MDB, it's hard to impossible to make a bound, editable
form based on a SQL statement written in Transact SQL dialect to take
advantage of Transace SQL features. Unfortunately, by trying to do so much
more, ADPs failed to adequately solve even the simplest problems that add the
most benefit.
David W. Fenton
> On Fri, 14 Oct 2005 13:44:43 -0500, "David W. Fenton"
><dXXXf...@bway.net.invalid> wrote:
>
>>"lylefair" <lylefa...@aim.com> wrote in
>>news:1129256956....@g14g2000cwa.googlegroups.com:
>>
>>> Sadly, I agree; ADPs were a great idea; they seemed to be
>>> wonderful.
>>
>>I don't see that ADPs were ever a great idea. The whole
>
> A crappy implementation does not make a great idea into a bad one
> - it's just crappy execution.
I'm not sure I understand what the "idea" of ADPs was supposed to
be, I guess.
>>justification for them seems to me to have been to avoid the icky
>>old Jet db engine. That so patently stupid an idea that I
>>dismissed ADPs on the front end, without ever needing to waste
>>hours, days and weeks trying to make them work.
>
> That might have been a motivation. What I personally wanted out
> of ADPs, and why I tried to use them, was to have a more seemless
> environment for doing development on applications that already had
> good a reason to be client/server, not to start writing apps as
> C/S that I would not otherwise have done that way.
I don't see why MDBs couldn't have had features added to interface
better with SQL Server, rather than throwing that out and starting
over to build the whole damned thing.
Also, so far as I understand it, ADPs depend for much of their ease
of use with SQL Server (and I note again the fact that it doesn't
even pretend to be a generic C/S front end solution, but just a SQL
Server front end solution) on the capabilities of ADO, which from
what I've read, seem to me to too "black box," making too many
decisions for the user so that you end up struggling against ADO's
assumptions about your data just as you did with Jet.
Had they designed a SQL Server-specific data provider, instead of
using a generic data access layer, perhaps that could have been
avoided.
> For instance, in an MDB, it's hard to impossible to make a bound,
> editable form based on a SQL statement written in Transact SQL
> dialect to take advantage of Transace SQL features.
So why did they choose to invent an entirely new fron-end format to
implament that, instead of altering the way MDBs work to allow that
to happen? I mean, they pushed the ADO integration for MDBs, too,
but it seems that MDBs don't really have much in the way of actual
features that are delivered via ADO functionality, after all. Surely
that would have been an area where ADO could have delivered
something that Jet/DAO couldn't.
> Unfortunately, by trying to do so much more, ADPs failed to
> adequately solve even the simplest problems that add the most
> benefit.
It seems to me that it was an unwise decision to try to implement
additional C/S (i.e., SQL Server) functionality by building an
entirely new front-end building platform, instead of by simply
redesigbing the old one to reflect the new environments in which it
can be used.
It could be that any of the single tasks that are such a benefit
would be much, much more difficult to implement in MDBs than in a
freshly designed format, but you'd save all the time of
re-implementing all the things that already *so* work in MDBs.
I'm reminded here of Joel Spolsky's article on why Netscape's
decision to chuck the existing codebase and start over was such as
bad idea:
Things you should never do, Part I
http://www.joelonsoftware.com/articles/fog0000000069.html
Seems to me that this is exactly what Microsoft did with ADPs --
threw it out and started over, instead of fixing the existing
codebase.
Steve Jorgensen
your assessment that ADPs were a bad idea. Better integration with database
servers, and even ADO might have been a very good idea, but ADPs were not the
way to go about it.
On Sat, 15 Oct 2005 15:11:14 -0500, "David W. Fenton"
<dXXXf...@bway.net.invalid> wrote:
I was starting to disagree on that, but I don't. Because better SQL Server
integration was a good idea does not mean a separate front-end format that
links directly to a single server instance was a good idea - so I agree.
The separate file format might not have been the only problem, or even the
worst problem, though. There was a huge problem with the spec. I think the
first BIG cause of trouble was MS deciding that because stored procedures are
like JET saved queries, stored procedure results should be editable! To do
that, they had to make modify the ADP spec, plus make sure ADPs could only
ever hope to work with a Microsoft SQL Server back-end. The ADP layer on the
client side has to actually know what table and row each field came from. It
goes downhill from there...
>Also, so far as I understand it, ADPs depend for much of their ease
>of use with SQL Server (and I note again the fact that it doesn't
>even pretend to be a generic C/S front end solution, but just a SQL
>Server front end solution) on the capabilities of ADO, which from
>what I've read, seem to me to too "black box," making too many
>decisions for the user so that you end up struggling against ADO's
>assumptions about your data just as you did with Jet.
How many points in there? Anyway, yes, yes, .... and yes.
>Had they designed a SQL Server-specific data provider, instead of
>using a generic data access layer, perhaps that could have been
>avoided.
I guess that might have worked, but not while trying to design it around a
pre-existing impementation of SQL Server (which they did - they started with
SQL Server 7). Funny enough, SQL Server 2000 adds a server-side "tabular
function" feature which is a much better option for allowing a client to edit
data returned from a server-side saved query than what they did, which was to
have the ADO client layer go around the server object, and update (or try to
update) the raw tables. Even though ADPs recognize SQL Server "functions" in
A2K2, they treat them just the same as SPs, so that's no help.
>> For instance, in an MDB, it's hard to impossible to make a bound,
>> editable form based on a SQL statement written in Transact SQL
>> dialect to take advantage of Transace SQL features.
>
>So why did they choose to invent an entirely new front-end format to
>implament that, instead of altering the way MDBs work to allow that
>to happen? I mean, they pushed the ADO integration for MDBs, too,
>but it seems that MDBs don't really have much in the way of actual
>features that are delivered via ADO functionality, after all. Surely
>that would have been an area where ADO could have delivered
>something that Jet/DAO couldn't.
If Access could reliably bind a form to an ADO disconnected recordset,
regardless of back-end, that would be blindingly useful. That's yet a another
simple, valuable possiblity that was not achieved.
>> Unfortunately, by trying to do so much more, ADPs failed to
>> adequately solve even the simplest problems that add the most
>> benefit.
>
>It seems to me that it was an unwise decision to try to implement
>additional C/S (i.e., SQL Server) functionality by building an
>entirely new front-end building platform, instead of by simply
>redesigbing the old one to reflect the new environments in which it
>can be used.
I was going to disagree with you on this, but I guess I do agree. I don't
think it was wise to try to eliminate JET as an intermediary to the server at
all - JET provides client-side glue that can be is highly useful and was
stupid to discard. I think, since Access already talks to JET at a lower
layer than DAO, instead of having the Access GUI talk ADO, they should have
enhanced JET to be able to query from ADO sources. Then you could do things
like bind a form to a query that joins a JET table to a SQL Server table, and
edit off-line using a disconnected recordset.
...
>I'm reminded here of Joel Spolsky's article on why Netscape's
>decision to chuck the existing codebase and start over was such as
>bad idea:
>
> Things you should never do, Part I
> http://www.joelonsoftware.com/articles/fog0000000069.html
>
>Seems to me that this is exactly what Microsoft did with ADPs --
>threw it out and started over, instead of fixing the existing
>codebase.
I think it might be overstating to say they started over. I'm sure they tried
to refactor existing code as much as they could. I think, rather, that the
biggest cause of trouble was a very bad spec.
lylefair
Steve Jorgensen wrote:
> If Access could reliably bind a form to an ADO disconnected recordset,
> regardless of back-end, that would be blindingly useful. That's yet a another
> simple, valuable possiblity that was not achieved.
Tell us of a specific replicable example where Access cannot reliably
bind a form to an ADO disconnected recordset.
Steve Jorgensen
I'm not going to try to replicate it again, but in several experiments at
different times, it always proved to be more often unstable than stable.
Basically, if you write an application that does anything with an ADO
recordset (disconnected or not) both through code when it is unbound and
through the form when it's bound, you see interface anomalies, like fields not
displaying values that they clearly have, etc. Shortly thereafter, Access
usually crashes and assks if you want to send the error info to Microsoft.
Even without these problems (which are slightly less bad in A2K than in A2K2
actually), there is the problem that Acccess keeps trying to reconnect to the
back-end for no reason. If, for instance, you sort or filter the data, Access
will reconnect, even though these operations seem to be performed on the
client-side with no necessity for a requery.
Larry Linson
> i think that you guys are crazy
Yes, you have made that clear. I expect many here "return the favor", too.
> all the action in the new version of
> ACCESS-- it has to do with ACCESS
> DATA PROJECTS
What you state is simply not accurate. And, in fact, almost no one who posts
here, other than you, are so bigoted in favor of ADP.
Some liked the idea of a "streamlined SQL Server client", but were turned
off by the impracticality of giving users full access to the SQL Server
tables. Perhaps, however, security is not an issue in your environment (it
has always been an issue in the environmets for which I have developed
database applications).
Some wondered why anyone thought it necessary to fix that which was not
broken (the Access MDB <-> Jet <->ODBC <-> server database approach),
particularly when the unbroken approach allowed Access to be a client to
_any_ ODBC-compliant database. Most of my paying work over the years has
been on Access clients to server databases, and only a minority of the
server databases involved were MS SQL Server.
> it is a much more reliable backend for your data
ADPs are not a backend; they are client applications accessing Microsoft SQL
Server (only). There are some workarounds to use classic ADO to access XML
tables, or text files, to simulate/emulate "local lookup tables" (which I
consider to be a distressing shortcoming of ADPs).
> i've just had too mcuh stability problems
> with a dozen users on Access MDB
I'd guess there are some here who would agree you have some stability
problems. I'd guess there are far fewer competent developers here who would
agree that there are any significant stability problems in a
properly-constructed split Access - Jet multiuser database.
I caution again, aaron, don't bet the farm on ADP / classic ADO / DAP being
"the future of Access".
Larry Linson
Microsoft Access MVP