Why isn't Access .NET-ized? Should it be?

[Banana]

I tried to look for a roadmap of where Microsoft want to take Access but to no avail.

Furthermore, I am a bit puzzled as to why they couldn't made a better use of it. Based on what I understand, Access is essentially an data-centric IDE with Jet database built in. All of Access objects have their special functions that you wouldn't have in VB6 (can anyone tell me if this is still true or not with .NET objects?) which makes data manipulation far more easier and with bound forms, you can do stuff much more quicker than if you did it yourself in a proper IDE.

But, wouldn't it have made more sense to provide those objects in a library that can be linked to .NET IDE, allowing us to choose any language and roll out solutions that perfectly match our needs without having to use ActiveX controls or cumbersome VBA routines (which can be done much better in a different environments).

Can anyone enlighten me on this? Do I have my preconceptions all wrong?

 

[pono1]

Hi, Banana,

I think part of the answer, if I understand a part of your question, is sales and marketing. Dot NET and the various languages it supports is Microsoft's answer to Java, Sun's programming language that dominated the enterprise programming market in the late 90s and early 2000s and still holds court today, though to a lesser extent. Access, on the other hand, was Microsoft's answer (long ago, 1992?) to Paradox and Foxpro and dBase, desktop database applications meant for advanced users and developers that target small office solutions (though, yes, Access has crept into big offices).

I'm not sure that "Access objects have their special functions that you wouldn't have in VB6" but I'm also not sure if I catch your meaning... Objects (like a DLL) used by a developer in Access can often be used by a developer working with VB6 or a .NET language...

Regards,
Tim

 

[Rabbie]

I have always got the impression that MS have targetted Access to be used and built by end users thus avoiding the need to involve the IT dept. This leads to the unique Access approach whereby many IT professionals dislike it because they feel it threatens their position and many good Access professionals do not have an orthodox IT background.

 

[Pat Hartman]

I guess I must have missed the train somewhere but I don't know what advantage incorporating .net would have in the Access development environment. Keep in mind that VBA is an interpreted language and not a compiled language as are all the .net languages. And as long as Access remains a "single file" solution, it will most likely remain an interpreted environment.

 

[Banana]

Thanks for the replies.

One major benefit, as I see it, of making it a library or add-in or whatever to a .NET environment would be to give the developers proper controls that has same behaviors as rest of the Windows. One example would be a textbox's scrollbar behavior. If you wanted to put in a large amount of text, it doesn't show scrollbar when it doesn't have the focus. This is not consistent with other textboxes you may see in a compiled .exe programs. Researching the issue, a MVP claims that this is because Microsoft decided to cut corners and deigned to give controls that used same bitmaps but were written specifically for Access (remember data centric events that didn't exist in VB6), this is why we have some controls that seems to be at odd with general Windows behavior. Same is true of tab control- looking at various solution, one could do much more with tab control's *default* property (and even could easily extend the property if desired) than with Access's dummy tab control.

Another thing to consider would be a pop up calendar. There's lot of people asking for this, and we have to roll out comparatively complicated solution for this, either using ActiveX (yuck) or borrowing MVP's 100-line codes to get same functionality that is a built-in in VB.NET. Microsoft tried to make Access extensible with ActiveX, but I don't think we need to go over why it has been largely avoided.

Finally, I do think that allowing one to choose language in a .NET IDE would even make Access a bigger of a RAD. If the developer happened to be a IT specialist desiring more control over a specific form but is content to allow Access to manage the rest, this can be possible. Right now, you either do it in Access and try to invent novel solutions to what VBA isn't really designed for or do it really hard way and re-write everything in a IDE.

Pat, could you explain why interpreted language would be such different, and is the answer for "single file" solution?

 

[Pat Hartman]

Compiled solutions start out as text files that when processed by a compiler are turned into executable files (.exe or .dll for example). These files contain only executable program code. They do not contain data so they do not change from one execution to another. With Access, both the code and the data exist within the same file. The file is more properly thought of as a container. Each time you run an Access appliation, its container .mdb can change. As long as the executable code resides in a "container", the operating system cannot execute it. Of course, that could be changed if MS so chose.

Access 2007 does include a native calendar control as well as a native file dialog. In fact, I think the file dialog is also available in A2003.

The problem with ActiveX controls is their distribution. If you distribute with the package and deployement wizard, they are taken care of.

And finally you need to consider complexity. VBA is intimidating to the non-programmer. They simply would have too much trouble with a .net language and despite Access' usefulness in the hands of professional developers, its target audience is the knowledge worker.

 

[Banana]

Pat, thanks for the explanation RE: compiling/interpreting.

Can you also tell me if AC2007 has the controls done better (e.g. they behave more consistently with the rest of Windows control, and there's no "missing" properties)? I'm surprised that you say file dialog is available in AC2003, which I have; I'll need to look at the documentations.

As for ActiveX, I thought there was other problems such as causing DLL Hell?

Finally, your point about VBA is interesting- Consider the knowledge users- if we are talking about a cubicle monkey who happen to be computer savvy but knows nothing about normalization or any of database theory, I'd imagine he would be able to pull off a simple contact database, or perhaps a simple sale invoicing database. This can be done entirely with Access objects without need for VBA. But once he wants to enforce just one little business rule, VBA rears its ugly head. You've already seen numerous posts here on the board asking for help which only showed that they *had* to know something about normalization, so they've already bit off more than what they can handle, so to speak.

Now on the other hand, if we are talking about using Access as a front end client for a fairly complex database with several of byzantine business rules, I'd wager that VBA (and inconsistent behaviors of controls) would want make a grown IT manager weep like a newborn when he knows that the amount of effort to set up controls to behave as he want would be significantly less in IDE, but is overshadowed by the fact that he'll have to write everything for the data binding and provide SQL for everything he does.

My point was more about the lack of granularity between those two scenarios. Access is totally great with those drag'n'drop development tools- it's now a nobrainer for anyone to design a pretty form that will show everything they need to see. But when they want a functionality that isn't within Access environment, the curve suddenly becomes very very steep. I kind of assumed that if one were to make Access an standalone add-in to a .NET IDE, this would provide the needed granularity as if you look through the .NET library, several cool toys already has been written and they are much easier to implement than ActiveX.

But I could be of course missing something very fundamental here.

 

[wazz]

i don't think you're missing anything, from what i've learned so far about .net, but you might be trying to stick a square peg into a round hole. i 'think' the main factor to consider - the only factor perhaps - is what pat was talking about.

.net is about the common language runtime (clr), intermediate language (il) and assemblies. and i'll stick my neck out a bit more and suggest that what you're pining for is visual studio (express). {tongue-in-cheek}

some FAQs. this link just touches on stuff (barely in some cases), but could lead you (or others) elsewhere.
http://msdn2.microsoft.com/en-us/library/ms973850.aspx

edit: i digressed a bit. i see what you're saying about the IDE etc., but...

 

[tehNellie]

This leads to the unique Access approach whereby many IT professionals dislike it because they feel it threatens their position and many good Access professionals do not have an orthodox IT background.

Prior to my time working with access my main disklike of it from a general point of view stems from:

1) People will create a database when they only really need a spreadsheet
2) having got their Access database up and running they don't actually know how to manage Access properly so you end up with 250mb databases with 20mb of data in them
3) Their little "widget" becomes mission critical and they end up turning our slow, but reliable, file servers into psuedo database servers.
3a) Access into these "systems" isn't being run to company policy

3b) All your mission critical data is now being held in a single user database, running on a file server, in a badly designed structure, that we weren't consulted about, don't know about and have never had any involvement with. Yet it will still be our fault when your PC crashes and takes all your data in Acess with it.

 

[pono1]

I would guess there is a building somewhere where Access coders and designers and project managers work. I would also guess there is another building or two where .NET / Visual Studio coders and designers and project managers work. Other buildings would be populated by people who market and sell the respective products. I would also guess there is very little interaction between the Access people and the .NET people. As a result, to integrate these two products would be a big project that would cost money...if both of these products are already turning a profit, it would be a difficult decision to re-design Access so that it plugs into the VS IDE...

Also, from the user standpoint, going from the Access IDE to Visual Studio is a big jump complexity-wise...

On the other hand, ActiveX is supposedly on the outs...not sure how Microsoft will move forward on the Access-front regarding this technology. Perhaps Access will ultimately go through the .NET framework...but with some new "features" built inside the Access IDE to shield users from the complexity of having to code to it...