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/

 

[Pat Hartman]

I think that discontinuing support for Jet will kill Access. How are non-programmers ever going to be able to deal with a "real" database? Jet also provides the db that holds an Access .mdb. Where will the application be stored in the future? I don't think that .adp's are ready for prime time. They are more limited than .mdb's and they do not allow you to link to anything but SQL server tables!!! There goes Access as a fe for Oracle, DB2, Sybase, etc.

Here's a link to the Microsoft contact page. I suggest that if this issue is important to you, you should make your opinions known to Microsoft.
http://support.microsoft.com/default.aspx?scid=fh;[LN];CNTACTMS

 

[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?

 

[Pat Hartman]

You can't click the link because the site messes it up. Copy the entire string and paste it. Make sure that you select the correct country and you will be redirected to the contact page.

 

[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...

 

[Pat Hartman]

The problem lies with Microsoft itself. Although they tell US not to use DAO, THEY do. So even in the newest versions of Access, DAO is necessary because the recordsets built for forms/reports are DAO recordsets. If you need to manipulate them using the RecordSetClone, you will be using DAO.

Also, I'm not sure that all the functionality of DAO has been ported to ADO. Aren't there still things ADO cannot do with Jet?

 

[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


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

 

[Pat Hartman]

My local Access users group is going to have a private "live chat" with Clint Covington who is the head of Access development at Microsoft. The meeting will be Wed Jan 12. If outsiders will be welcome, I will post the time, etc. For the Connecticut members and others close enough, the meeting is in the Farmington, Ct Microsoft offices off the Fineman Rd exit from I84. Farmington is between Waterbury and Hartford on I84 but closer to Hartford. If you haven't come before, this will be a good meeting to start with.

 

[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.

 

[Pat Hartman]

Don't confuse the engine for Access with the engine for the data. I agree that there are far better database engines than jet but jet not only manages native Access tables but it also manages the Access .mdb itself. When you "upsize?" to an .adp, you loose the security provided by Jet. You can still secure the tables but you can no longer secure the db objects. Not that I am a fan of Jet security but some people have worked out how to use it. The point of the .mdb as we now know it is that it lets us CHOOSE our prefered database engine. You don't have a choice any longer when you upsize to an .adp. You VILL use SQL Server tables! You have no other choice including jet.

 

[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

 

[Pat Hartman]

According to Clinton Covington, the manger for Access development at Microsoft, the Access team is as big as it has ever been and they have big plans for Access. There is supposed to be a new Office version next year. Given the development lead times, it is probably already in beta testing or close to it. The big team is most likely on board for the next version which is at least in the planning stages and may already be in development.

 

[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