MS Drops support for Jet...

[WindSailor]

This was thrown my way a little while ago... and actually it is old news

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mdacsdk/htm/mdac_deprecated.asp

When you go to the web page: In the left hand column: click on "Deprecated Components"


Deprecated Components

Each of the following components is considered obsolete. While these components are still supported in this release of the Microsoft® Data Access Components (MDAC), they may be removed in the future. When writing new applications, you should avoid using these deprecated components. When modifying existing applications, you are strongly encouraged to remove any dependency on these components.
ODBC Provider (MSDASQL)

You are strongly encouraged to use one of the native OLE DB Providers instead of the Microsoft Open Database Connectivity (ODBC) Provider. Native OLE DB Providers provide better application stability and performance. Furthermore, native OLE DB Providers will be supported in the future, whereas MSDASQL will not have any new features added to it, will not be available on 64-bit, and will not be accessible from the OLE DB NET Data Provider.
Remote Data Services (RDS)

Remote Data Services (RDS) is a proprietary Microsoft mechanism for accessing remote data across the Internet or intranet. Microsoft is now shipping the Microsoft Simple Object Access Protocol (SOAP) Toolkit 2.0 that enables you to access remote data using an open, XML-based standard. Given the availability of the SOAP Toolkit 2.0, you should migrate from RDS to SOAP. The SOAP 2.0 Toolkit 2.0 also includes sample code for remotely accessing Microsoft ActiveX® Data Objects (ADO) Recordsets.
Jet and Replication Objects (JRO)

The Microsoft Jet OLE DB Provider and other related components were removed from MDAC 2.6. Microsoft has deprecated the Microsoft Jet Engine, and plans no new releases or service packs for this component. As a result, the Jet and Replication Objects (JRO) is being deprecated in this release and will not be available in any future MDAC releases.


It is going to be interesting to see if Microsoft will in their next Access release, have the ability to automatically upgrade previous versions to the current engine (what ever it is... MSDE2000 or SQL Server 2005 Express etc.) I would sincerely hope so...


Free alternatives from Microsoft...


Microsoft SQL Server 2000 Desktop Engine

http://www.microsoft.com/sql/msde/default.asp


SQL Server 2005 Express

http://www.microsoft.com/sql/express/

 

[AN60]

Pat
I can't get your link to work properly. That aside, I wonder if Access is to be killed off & replaced or just killed off?

 

[WindSailor]

I have called Microsoft and asked that they respond to this thread...
Their first response was that of commitment to the lifecycle of all current versions of Access using the jet engine (I believe the life cycle support of an application is 7 years...(?)).
As for the future of Access and which engine, connectivity etc... the person(s) that I talked to couldn't elaborate on this aspect because it was simply out of their area of responsibility.

 

[WindSailor]

I have recieved a reply...

_______________________________________________________________


This is in reference to the case *************, expressing your concern about the deprecated components and their effects as a database. I have some updates that I found on the MSDN and also have confirmed the same. I am including my findings in this mail. Please do not hesitate to contact if you have any further questions or queries relating the same. You can contact me on the numbers mentioned below or just reply to the email and I will get back to you as soon as possible.

Findings and completed actions:
----------------------------------------
ïƒ The link suggested by you is absolute correct.
ïƒ Microsoft does identify some of the technologies as 'Deprecated Components'.
ïƒ However such components are supported in the current release of Microsoft products, but might be removed in future releases. When you develop new applications, avoid using these components. Additionally, when you modify existing applications, remove any dependency on these components.
ïƒ Further to add there are new features being developed which handle certain issues which do come in and have been know to affect the productivity of the databases.

Here are some of the excerpts from the one of the MSDN articles:

Obsolete Data Access Technologies:
Obsolete technologies are technologies that have not been enhanced or updated in several product releases and that will be excluded from future product releases. Do not use these technologies when you write new applications. When you modify existing applications that are written using these technologies, consider migrating those applications to MDAC or ADO.NET.

The following components are considered obsolete:
• DB-Library: This is a SQL Server-specific programming model that includes C APIs. There have been no feature enhancements to the DB-Library since SQL Server 6.5. Its final release was with SQL Server 2000 and it will not be ported to the 64-bit Windows operating system.

• Embedded SQL (E-SQL): This is a SQL Server-specific programming model that enables Transact-SQL statements to be embedded in Visual C code. No feature enhancements have been made to the E-SQL since SQL Server 6.5. Its final release was with SQL Server 2000 and it will not be ported to the 64-bit Windows operating system.

• Data Access Objects (DAO): DAO provides access to JET (Access) databases. This API can be used from Microsoft Visual Basic®, Microsoft Visual C++®, and scripting languages. It was included with Microsoft Office 2000 and Office XP. DAO 3.6 is the final version of this technology. It will not be available on the 64-bit Windows operating system.

Some notes and related links:
-------------------------------------
Executive Chat with Richard McAniff: Office XP as Development Platform
http://msdn.microsoft.com/chats/office/office_052002.asp

MDAC Road Map
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmdac/html/data_mdacroadmap.asp

I hope I have been able to provide satisfactory information. Please do not hesitate to contact me in case of queries or suggestions.

Thanks and regards,
**************


_______________________________________________________________

Hopefully this will help people in their concern with Microsofts direction pertaining to MS Access, especially with the 64-bit Windows operating system.

If anyone has ideas/suggestions, please call Microsoft.

 

[misunders2d]

probably it's the time to get rid of DAO finally.. However, taking in account that direct sql usage (DDL) in access is incomplete, lacking some basic fuctionalities, DAO was a nice way to smooth it. ADO has huge advantages, but correct me if there's no coder left still using DAO technology...

 

[WindSailor]

Found this excerpt basically defining DAO and ADO...

-----------------------------------------------------------

The DAO object model is designed specifically for the Microsoft Jet database engine. Jet itself incorporates ISAM and ODBC connectivity and makes the back-end providers look as much like the native Jet engine as possible, though this comes at the expense of performance. DAO also has an ODBCDirect mode that allows it to host RDO objects and access ODBC datasources in a very efficient manner.

The ADO object model was designed for OLE DB providers and is a much simpler and more flexible object model than DAO. However, its architectural design poses some problems when using the Microsoft Jet OLE DB provider, and it is more limited than DAO in Jet functionality it supports.

-------------------------------------------------------------------

 

[WindSailor]

Here are some more links given to me by Microsoft...
I have found these extremely helpful...


---------------------------------------------------------------------------

225048 INFO: Issues Migrating from DAO/Jet to ADO/Jet
http://support.microsoft.com/?id=225048

168335 INFO: Using ActiveX Data Objects (ADO) via Visual Basic
http://support.microsoft.com/?id=168335

184233 INFO: Using ActiveX Data Objects(ADO) Through Microsoft Access 97
http://support.microsoft.com/?id=184233

177138 INFO: Nested Transactions Not Available in ODBC/OLE DB/ADO
http://support.microsoft.com/?id=177138

311058 INFO: Microsoft .NET Framework Does Not Support Data Access
Object
http://support.microsoft.com/?id=311058

283883 ACC2002: New Access Databases Do Not Include Reference to
Microsoft DAO
(original kb article 283883 wasn't there... redirected to 225962 - Rick)
(when adding references - be sure to have DAO above ADO - Rick)
http://support.microsoft.com/default.aspx?scid=kb;en-us;225962

319400 ACC2002: Conversion White Paper Available in the Download Center
http://support.microsoft.com/?id=319400

Executive Chat with Richard McAniff: Office XP as Development Platform
http://msdn.microsoft.com/chats/office/office_052002.asp

MDAC Road Map
(original link was denied... used link from above... - Rick)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmdac/html/data_mdacroadmap.asp

KB304701: ACC2002: How to Troubleshoot Corruption in a Microsoft Access
Database
http://support.microsoft.com/default.aspx?scid=kb;EN-US;304701

KB283849: How to troubleshoot and Repair a Damaged Access 2002 or later
Database
http://support.microsoft.com/default.aspx?scid=kb;EN-US;283849

KB303528: HOW TO: Keep a Jet 4.0 Database in Top Working Condition
http://support.microsoft.com/default.aspx?scid=kb;EN-US;303528

KB295334: ACC2002: Jet Compact Utility Available in Download Center
http://support.microsoft.com/default.aspx?scid=kb;EN-US;295334

KB198755: How to determine who is logged on to a database by using
Microsoft Jet UserRoster in Access 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q198755

KB209161: Microsoft Access and Untested Networks
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q209161

KB274278: ACC2000: How to Run SaveAsText/LoadFromText on Multiple Access
Objects
http://support.microsoft.com/default.aspx?scid=KB;EN-US;274278

Windows Update
http://v4.windowsupdate.microsoft.com/en/default.asp

Office Update
http://office.microsoft.com/productupdates


----------------------------------------------------------------------

 

[WindSailor]

Here is my 2 cents...

Personally I believe that Access has or plays a major role in personal database development. I guess what I mean is that it is a great introductory database program that can be used to create complicated databases as an individual or their certain needs grow. I hope that part never changes.
But, as for a developer that wants to build something that he or she can use or distribute among a variety of people and their varying operating systems, I find Access has a lot of issues and a grand pain in the ars! Those issues are actually driving me away from Access!
That part I want changed!
Support has asked my opinion about it and I requested that the engine for Access in 2005 be 2005 SQL Server Express, but I added that Access still needs to be a dynamite front end for other databases also.

People are always looking for alternatives... for instance

www.vistadb.com

Opinions?

It seems like Access is stuck in a situation similar to what the windows operating system was going through… either support functionality or stability.
If the question is to drop DAO for added stability, updatable mainstream security issues etc. when moving to the 2005 SQL Server Express as an engine… then I am for it. But that also means that Microsoft will have to add support that will make up for the lost functionality using DAO with added support for ADO.
Programming language… I will leave that one alone for now.
Maybe I am wrong here, I am trying to read between the lines, but it seems that a lot of things are hinging on the .Net 2.0 framework coming out next year etc.

 

[shadow9449]

Does this mean that future versions of Access will have a better database engine than Jet? Or does it mean that MS is scrapping Access altogether?

Jet is not the best engine out there. My preference for Access is because it's very easy to use, very quick to design forms and link them to tables. I found that it took a fraction of the time that it used to take me to create databases using VB.

I would be happy to see them replace the database engine, but so long as they keep the front end form/query/report development which links easily to the tables from a property sheet, then I'm fine.

SHADOW

 

[RoyVidar]

Interesting thread, with lot of interesting thoughts.

One of the things occupying me, isn't really the DAO vs ADO, and the Jet Engine, but the consequence of what's happening with VB. Windsailor left that element out, but I think that's something that perhaps belong in the discussion.

Access, as the other Office applications, and VB is built on top of the VBA engine, and as such, I'm assuming, exposed to the same "threats". Some say there isn't any VB7, some say VB7 is VB.Net, but nothing has happened to VB (the VBA engine) since VB6 (Access 2000). What we've seen are a couple of new properties and methods, but that's related to Access object model, not VB(A).

In this article
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsmart03/html/sa03e1.asp

This is the second paragraph:

"Why talk about .NET in a Microsoft Access publication? Because some day, Microsoft Office is going to be "DotNetified" and we might as well get ready for it. While it's true that the next version of Office isn't a .NET product, competitive Access developers will use this reprieve to prepare for .NET. Now is the time to identify ways to leverage your current Access skills and find your own .NET niche."

We've probably seen the latest version of DAO, but how long will ADO keep up? .Net seems to be the way Microsoft is heading, which makes me inclined to believe ADO may perhaps be on the same list in a while. As to when it happens, I won't guess. It's been a while since the "Death of DAO" was proclaimed, and it still lives, even within Access 2003 (as Pat Hartman elaborates on regarding form/report recordsets).

So my "fears" or thoughts is that the discussion of DAO vs ADO, is perhaps also "outdated", and that that both tehcnologies are probably dying at the same speed, to be replaced with ADO.Net?

Well, even if ADO doesn't die together with DAO, I don't think we'll see much "Jetification" of it.

But what happens to Access? I'm on a complete guessing tour here, but I do believe (or perhaps the correct term would be hope) in the continued existence of Access, but perhaps not in it's current form. I think we'll see the same core concept of Access being Grandmas Drag-N-Drop recepie database, but also with better, and easier to use connectivity to other databases (improved ADP's?). I think we'll see VBA replaced with VB.Net at some stage, I think, because of that, ADO.Net (or other/newer technologies) to replace DAO/ADO.

Pat Hartman, if some of the things you discuss at your meeting touches the themes discussed here, I don't think I'm alone in hoping you'll post something here...

 

[shadow9449]

Hi, Roy

I've been programming VBA for many years (and VB, most recent version I've used is 6, for a while). I know almost nothing about .NET. In idiot's terms, can you explain what it is, how it's different than VB(A), what it accomplishes differently, and, in practical terms for the programmer, what tools would I need to buy (from Microsoft, of course) to use it, and how difficult is it to learn for a VB(A) programmer?

Thanks

SHADOW

 

[WindSailor]

I should let Roy respond to this, but VB.Net is a BIG jump from VB6 or VBA. A lot of methods or I should say some methods are no longer supported in VB.Net when upgrading from VB6 or VBA, so depending on how much programming you have done in your application, extensive or otherwise, will depend on how fast you can upgrade.
If your program extensively uses code to accomplish your goals, then you are actually better off starting from scratch in VB.Net and rebuilding your app.
There may be third party applications now that may help in the process, code generators etc. but I haven’t looked at this part in a while. I do this basically as a hobby and it is hard to keep up with when it is moving this fast.

Most articles on VB.Net suggest that the average time to get into your comfort zone in VB.Net coming from VB6 is approximately one year maybe longer, depending on how much time you spend with it.

Microsoft is coming out with a different style of Visual Studio tools to get into programming…
These are still beta, but should come out in the first half of 2005. Worth a look.

http://lab.msdn.microsoft.com/vs2005/default.aspx

One interesting point that should be said is that the .Net idea was to abolish “DLL Hell” and writing to the registry (you basically write STRICTLY from the classes etc. that are within your framework), with that said and from what I understand is the .Net 1.1 framework is NOT backward compatible with the .Net 1.0 framework, so if you have apps that are built off of both frameworks you will have to have both frameworks installed on your machines. Hopefully with the .Net 2.0 framework and above this issue will be corrected, or this is the main idea that Microsoft has and you will just have to install your “correct dll’s” on your machine in order for your apps to run. Interesting though…

Moving Access/Office to .Net I would suppose is not going to be an easy task, and I would assume Microsoft has been working on this for a while now.

 

[shadow9449]

Hi, Rick.

depending on how much programming you have done in your application, extensive or otherwise, will depend on how fast you can upgrade.

I probably will leave my Access applications as Access applications. It's not as if Microsoft will be able to pull a switch somewhere and knock my clients off their successfully running programs (I'm sure they would if they could, though )

My consideration is for future applications. I was digging around the .NET documentation on MS, and it seems that you design your forms using code, and you bind data using code. That is a much more time-consuming route than the old drag and drop, WYSIWYG, visual development interface that makes me use Access. The formula is simple: less development/debugging time for me = lower cost to end user, making me more competitive, and I'd hate to give that up by having to hand code every form I design.

One interesting point that should be said is that the .Net idea was to abolish “DLL Hell”

I've never had to create a DLL in Access

Have a happy New Year.

SHADOW

 

[shadow9449]

Pat:

Thanks for the information.

According to what you're saying, Access isn't going anywhere in a hurry, and as a worst case scenario, we Access developers will just have to add more tools to our kit to be able to produce better applications.

My biggest complaint about Access is that it is not intended for a WAN. It would be really nice to have several sattelite offices operating off one database. Writing ASPs for this purpose is not as easy as simply hosting the application on a server and setting up the VPNs.

A more robust DB engine may be more ideal.

SHADOW

 

[shadow9449]

I know that you CAN use it, but I've read many places that it's not recommended, as Jet is not really equipped for that type of thing. It's too prone to corruption (like the kind you get when the network fails) to use on a regular basis.

If you've had success over a WAN, then let me know. Maybe I'm just falling prey to Microsoft's scare tactics in their effort to make people buy SQL Server!

SHADOW

 

[bjackson]

Here is an interesting extract from an article that i have read (late Nov 2004)

MICROSOFT INVESTING HEAVILY IN ACCESS

Last week at the Access Advisor conference in Las Vegas, Microsoft announced their plans for enhancing Access over the next several versions. In his keynote, Richard McAniff, Corporate Vice President of Access, Excel and Office Programmability, revealed the future direction for Access and their renewed commitment to the roots of making databases easy, along with SharePoint integration for web connectivity. With the largest Access development team since the early days of Access, Microsoft is refocusing its efforts on making Access the no-brainer choice for Excel users who need more power. By simplifying the development of database applications, information workers will be empowered to solve more database problems on their own. Meanwhile, the developer features will allow the continued creation of professional solutions. Overall, the investment Microsoft is making, the change in focus and simpler marketing message for Office, is quite tremendous and bodes well for the future of Access.

At ######## we are extremely pleased to see this new focus. Rather than focusing on SQL Server or .NET, Microsoft is returning focus to Access' core strength

#######################################
#######################################


My two bobs worth
In the end i think ms would have a hell of a job selling the idea of not supporting Jet/access-maybe they are just testing the water.A bit like politicians,if they dont get much negative feedback,then they WILL do it,otherwise they will just say they have no idea where or from whom that nasty rumuor started

Bjackson

 

[dotnetfirebird]

Access replaced by Firebird SQL

I have replaced Access with Firebird SQL. It is a full-featured database that can also be embedded (the runtime is < 2 MB). See e.g. http://www.dotnetfirebird.org/blog/2005/01/firebird-and-microsoft-jet-feature.html.

 

[WindSailor]

>Why does everyone confuse Access with Jet?

Because it is synonomous... and a lot of us assimilate it as a whole.

>Firebird SQL is a replacement for Jet, not Access unless I am reading the add incorrectly. Oracle, DB2, SQL Server, MySQL, etc. are >ALL replacements for Jet.

Previously I stated...

Support has asked my opinion about it and I requested that the engine for Access in 2005 be 2005 SQL Server Express, but I added that Access still needs to be a dynamite front end for other databases also.

and your response was...

>Don't confuse the engine for Access with the engine for the data.

OK... I am probably getting a little confused...
Maybe you should expand on this...

I still think the default database for Access 2005 should be 2005 SQL Server Express, this is the base line for Microsoft and it is a mainstream product, why would Microsoft ever consider something else for a database in their database introductory program besides a mainstream product?

When I first got into Access the FIRST thing I heard was that security was a problem, and there were a lot of holes to patch to make it secure. This was to my understanding geared toward the Jet structure.

Pat, you are the most dedicated person that I know of here on this forum towards Access. What do you want in the next version of Access?

There is a niche for a more of a stand alone product that is more robust and more open towards developers needs for developing database programs than Access currently has, does Microsoft have a desire to go in this direction, does Microsoft even care to cover this niche or is Microsoft just happy to have an introductory program and settle for that?

I know you have a meeting with Clive here shortly, I hope this will inspire other developers to make their comments here... and I would love to hear your remarks about the meeting.

 

[WindSailor]

Great response... and very well put. Thank you.

I will honestly bet you, that you don't loose too many arguments do you?

Can I have more of what you are eating?

 

[shadow9449]

With the current configuration, Access scales up quite nicely. You can substitute linked ODBC tables by simply replacing the local Jet tables with links to a RDBMS

We discussed doing this a few weeks ago, but I don't think I ever succeeded. Is there instructions for this for the utter dolt (meaning me) somewhere on this forum, or on MSDN, or elsewhere?

What I want to accomplish (once I figure this all out) is to somehow create an Access database, convert the tables to MySQL (which works really well on the web), then give many users at many physical locations (perhaps different cities) an identical front end that taps into the hosted MySQL tables. From what I've read, this is possible. But I'm clueless as to where to begin. IF I can get this going, then there's no reason not to have 20 people in different cities (perhaps a chain of retail stores all checking inventory online, and head office getting sales figures in real time) using Access-based databases (Access-based meaning that I started out in Access, and just migrated to MySQL)

I wouldn't mind trying to figure out how to use MSDE to make my networked databases more robust, but I don't understand enough about MSDE to actually use it. I'm reading Microsoft's courses on the topic, although they relate more to .adp, but I am hoping that I'll get enough understanding of MSDE that way.

The drawback to staying with a single container for both objects and data is that it will never be possible to compile your app into an .exe.

If you are worried about people stealing your objects, wouldn't an .mde prevent this?

I would like to see the tables permanently removed from the .mdb so that all Access apps require two files. The .mdo (new extension) that holds the objects and the .mdb that holds the data. With that separation it would be possible to create a compiler so that a more secure compiled application could be delivered.

This isn't very different than what we all do with a front end/back end application....would be nice to be able to just compile the front end.

When is your meeting with Clint Covington?

SHADOW