Access as a web tool is S*H#I.T......that is NOT what MS Access was designed to be or ever do. You can never do more than you were designed to be......Microsoft Office, since 2007 has JUMPED THE SHARK....
Microsoft doesn't give a S*H#I.T about its user base....its focus is on the NEWBIE users who don't take the time to learn NEW SKILL SETS....which is why that Piece of S*H#I.T ribbonX technology was developed....
I personally won't use or purchase any more MS Office products - sticking with MS Office 2003.....and if I ever consult again, I will AGGRESSIVELY PURSUE A DEVELOPMENT STRATEGY WITH COMPANIES TO MOVE THEM RETROGRADE TO MS OFFICE 2003 IF THEY are using new
versions of Office.....
Microsoft is a dying company.....while I certainly don't think winapps are dead.....WPF, MS Blend....and all those other BS apps are overkill for true software development in my opinion.....
One of the best MS tools ever created was Front Page....and Microsoft S.H.I.#T canned that for some clunky version of Web Developer .Net atrocity....
Don't get me wrong....I love VB.Net....I'm a fan....but SQL Server blows and ANY backend technology by MS blows as well....but I do think MS nailed it with its front-end development tools like Visual Studio.....
Great time watching this demo......I'm floored in a few ways but not in the way you might think. I'm an Access developer and have been for almost 10 years......
A few comments and opinions on the "new" Access 2010.....
1) If ever there were a truth about a Microsoft product, it certainly holds true for Office 2007 and beyond....which is, that THIS PRODUCT HAS JUMPED THE SHARK......Microsoft has OVERPRODUCED it.....the ribbon sucks, the new application facelift is virtually
unnavigable, and relative to MS Access, you've removed the data window and jacked around all the data filter commands....WTF?
2) MS Access 2007+ is virtually unusable for a developer. It is cumbersome to work in at best. I cannot work in these versions and I REFUSE......I REFUSE to develop a solution in MS Access 2007+ USING MS Access 2007+. For the FORSEEABLE future, I will continue
to develop MS Access apps in 2003 and test them on later Office platforms when necessary. If you are going to retard the product with a useless ribbon, could you at least have some sympathy for the f*^&%^ing developers of the product (also known as your LOYAL
user base) and provide a user option to return to a "classic version" configuration?
3) Macros have always been a joke (in my opinion). If you are going to develop an Access application for a business, you should be working directly with VBA not macros.....with rare exception the only macro necessary to use in VBA for Access is the AutoExec
macro which kick starts the application with the opening of the main form. But in Access 2010 you've REFOCUSED efforts to further dumb down the app by employing all that * interface for macros? It's an overproduced waste of time......
4) It's great that you want to reincarnate MS Access from a WinForm solution to a hybride WinForm+WebBased solution.....I'm ecstatic that Microsoft is not going to deprecate Access from the world at large since quite frankly, it's the only damn product that
Microsoft ever TRULY got right.....(you could argue that Front Page was another extraordinary MS product but where is it today?) That's right, Microsoft has shitcanned that app for a clumsy version of VS Web Developer........again, another product that jumped
the shark....back to the point....MS Access 2010 has been reincarnated to work seamlessly with SharePoint.....great.....give me an add-in that I can use for MS Access 2003 and I'll use it....otherwise that shitball of an application is useless....
I hate to be so hard on the hard-working efforts made by MS devs who have contributed to this product but, I have to tell you that you are developing this application IN ALL THE WRONG DIRECTIONS......
AS an aside, VISUAL STUDIO devs could learn a few things by employing some of the elegance and simplicity that comprises user navigation and UI in MS Access 2003. Let me see, let me develop an app using VB.Net and try to connect to a database, develop FLEXIBLE
reporting and then hand it off to the user.....let me do the SAME thing in MS Access 2003 and the entire effort is about 70% less work.....VS 2008 database connections include fucking adapters, binding sources, datasets, table adapters, etc.
Let me SCREAM AT THE TOP OF MY FUCKING LUNGS for some functionality pieces in MS Access that developers around the world are looking for......it's another waste of keystrokes here though because no one at MICROSOFT IS LISTENING....but if this rant doesn't
get canned from the Channel 9 site at least it will show some semblance of freedom of expression here as well as openness to L I S T E N.
SOME OF THE MOST POPULAR MS ACCESS FUNCTIONALITY THAT THE ACCESS DEVELOPER WORLD REALLY WANTS:::::::
1) Ability to convert mdb or accdb into EXECUTABLES
2) Ability to encrypt and/or lock tables separately or all of them simultaneously
3) INCREASED SELECTION OF CONTROLS FOR MS ACCESS DEVELOPMENT
4) Increased file capacity from 2GB to say 100GB
5) Better documentation tools integrated into the VBA Editor (Ex: ability to export COLORIZED VBA code documents)
6) More datatypes added to enrich what can be stored in Access tables
7) Better (MUCH BETTER) graphing capabilities for charting data
8) Increased VBA language capabilities that parallel VB.Net
There are many more needed improvements but the aforementioned is a start.
Now, MS decision makers, go back to your development shacks and forget these opinions were ever expressed...
You showed us how to create an embedded manifest in VS 2005 but what about embedding one in VS 2005 Express Edition?
There is no manifest template there for that.
My guess is that we should just copy a manifest file from a sample VS 2008 app into a VS 2005 project file. Is this correct?
Since both are running on variations of the 2.0 framework it shouldn't be a problem. Is this correct or is there another more appropriate way in which to create an embedded manifest in VS 2005 Express Edition?
What on earth is wrong with managed code? What is your beef with VBA being ported as managed code into Visual Studio?
I think the reality is that it's not outside the scope of possibility that VBA will be ported into a managed code construct within Visual Studio some time in the future.
I personally wouldn't mind being able to use VBA's DOCMD functionality which is currently supported in MS Access as managed code within Visual Studio if it were to be ported in that fashion.
If VBA is restructured in the future within Visual Studio, well, that's just the nature of change - .Net will reverberate change in the technology world for some time to come in unique and diversified ways.
I welcome new and improved ways to code even if it means restructuring or eliminating VBA - by the way, I am a strong supporter and avid user of VBA in my MS Office applications.
I think this video is one of the most exciting videos hosted on Channel 9.
After watching this video, my blood started pumping a little bit faster....why? Because I can foresee my annual salary increasing about 15K a year within the next 2 years as a result of the incredible things I will be doing with the Office add-in capabilities
in VS 2005.
Your products are truly world class...
Thank you Microsoft!
P.S. Will the Office add-in also be provided for VS 2005 Standard edition, or just the Team Edition?
The website for additional information on Office development tools can be found at:
If it's true what you say about not being able to locate Microsoft's XHTML XSL transform, I wouldn't be surprised if it was subsequently replaced with a new programming protocol called XAML (Extensible Application Markup Language) which will be incorporated
as part of the next version of Visual Studio after whidbey codenamed ORCAS to be incorporated with the use of Longhorn.
...all these MS codenames makes one sound like king of the Geeks...
I wanted to commend you and your staff for developing such extraordinary community tools for developers.
However, I would like to contribute an idea to the mix. I think it would be additionally helpful if a distinction on the pinvoke website could be made between API's that do and don't have managed code counterparts for later versions of Visual Studio.
As you know, eventually Microsoft will convert all unmanaged code to managed code which will obviate the need for incorporated APIs. Given the fact that many companies will not upgrade their VS development tools as quickly as new ones come to market, a website
that could provide a comparison of sorts between VS that has a managed code counterpart against earlier versions that don't would be not only helpful but signifcantly educational in reducing the learning curve in knowledge transition from unmanaged to manage
code development skills.
For example, to play sound wavs in VS 2003, one needs to incorporate an API. In VS 2005, that code has been converted to managed code, thus obviating the need for an API.
The "My" namespace in VS 2005 also converts many of the APIs in previous versions making them obsolete. I'm not suggesting that API incorporated code should be eliminated from the PinVoke website, but that it would be nice to have some kind of web interface
that could quickly identify and define:
1) Managed vs unmanaged code capabilities between Visual Studio versions,
2) Upcoming anticipated managed code solutions for the next version of Visual Studio,
3) an obsolete listing of unmanaged code solutions based on particular versions of Visual Studio
I acknowledge that this idea is forward thinking, but it serves to reduce the confusion that will inevitably ensue over time during VS version transitions and upgrades between unmanaged and manage code.
If these ideas sound nebulous, please respond and I will elaborate.
I believe that .Net framework namespaces will continue to grow exponentially over the coming years so moving to proactively accommodate version distinctions now relative to unmanaged/managed code solutions will serve the world developer community quite well.
I hate to be a ball buster to all those who have provided their solutions for the palindrome problem but I was able to solve the problem in less than 5 minutes using Visual Basic.Net.
Even the Visual Basic solutions that I read were, in my opinion, over-analyzed!
You guys are overthinking things. What I try to do when I code is to think about a problem in terms of SIMPLICITY. Have we all forgotten the cliche? KISS - keep is simple stupid!
Sounds like those of you who are using VB.Net need to be MORE aware of the incredibly power FUNCTIONS that are included in the current version of Visual Studio. It makes all the difference in the world...
Here is the VB code I've come up with - it's 5 lines:
If Me.txt1.Text = StrReverse(Me.txt1.Text) Then
Me.txt2.Text = "True"
Me.txt2.Text = "False"
The code entails 3 objects - 2 text boxes and a button. Attach the code to a button control and
you are done.
The code handles punctuation, nulls, whitespaces and is even case sensitive meaning, this code recognizes case sensitive palindromes, so AbBa would not be considered a palindrome using this algorithm.
Now, depending on what side of the philosophical argument you are on in terms of what constitutes a palindrome relative to upper and lower case letters, the code I provided can be minimally tweaked to accommodate the palindrome for either interpretation. All
that is needed to recognize mixed case palindromes is to integrate an additional function (UCase) to the mix.
I found this problem interesting but fairly easy to solve.