If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
Opening Access db via DAO in vb.net
"Michel Posseth [MCP]" wrote in message ... Recomended by who ? as MS did not even bother to develop a 64 bit Jet oledb driver for Access this means that even ADO.Net can`t work with Access so in my opinion MS doesn`t want you to use Access at all in newly to develop products . that is probably also the reasson why in all study materials , examples etc etc only connections to one of the SQL family`s is shown ( wich by the way do have 64 bit equivalants ) By the vast majority of people I speak to who are still developing solutions in Microsoft Access using the Jet database engine. Regardless of whether they should be there are still a lot of them and the overall performance of ADO when working with Jet is, frankly, abysmal. DAO `s perfomance is superb on ACCESS , as it is a specialized engine optimized for this database However my question is should you use a long time ago fased out technology in a newly developed product ? Probably not, however I never stated an opinion for or against Jet as a suitable solution for John's application. I presume he has his reasons for choosing it over more current technologies. And if we are talking about perfomance lets put the cards right and compares against SQL server CE wich is the substitute for a Access database in .Net I'm sure you're right. Nevertheless DAO is, in most cases, *much* faster when working with Jet than ADO. As John is using an MDB file I would strongly recommend he tries DAO as well as ADO as, in my experience, it may make the difference between a usable and unusable system. Ed Metcalfe. |
#12
|
|||
|
|||
Opening Access db via DAO in vb.net
"Michel Posseth [MCP]" wrote in message
... http://msdn2.microsoft.com/en-us/library/ms810810.aspx scroll to the bottom to see that DAO is officially declared Obsolete ( a long time ago ) note: that this paper was released the first time in January 2002 but it was known to the programming comunity long time before that At our last MVP Summit in Seattle, we were specifically told by Microsoft that DAO is the preferred method of dealing with JET and SQL-Server databases from Access front-ends, reversing decisions made ssome time ago. ADO is obsolete, having been replaced by ADO.NET. The design structure of Access for dealing with databases is so complete and therefore complex, that I believe that there haven't been any .NET efforts made to work with it yet. It may be several years before Microsoft builds any .NET capability into Access. Until then, DAO is the faster and more complete method of dealing with JET data. -- Arvin Meyer, MCP, MVP http://www.datastrat.com http://www.mvps.org/access http://www.accessmvp.com |
#13
|
|||
|
|||
Opening Access db via DAO in vb.net
"Arvin Meyer [MVP]" wrote in message ... At our last MVP Summit in Seattle, we were specifically told by Microsoft that DAO is the preferred method of dealing with JET and SQL-Server databases from Access front-ends, reversing decisions made ssome time ago. ADO is obsolete, having been replaced by ADO.NET. The design structure of Access for dealing with databases is so complete and therefore complex, that I believe that there haven't been any .NET efforts made to work with it yet. It may be several years before Microsoft builds any .NET capability into Access. Until then, DAO is the faster and more complete method of dealing with JET data. -- Arvin Meyer, MCP, MVP http://www.datastrat.com http://www.mvps.org/access http://www.accessmvp.com Arvin, Is this information published on the Microsoft website anywhere? The most recent article I could find was this: http://support.microsoft.com/kb/225048 Ed Metcalfe. |
#14
|
|||
|
|||
Opening Access db via DAO in vb.net
At our last MVP Summit in Seattle, we were specifically told by Microsoft that DAO is the preferred method of dealing with JET and SQL-Server databases from Access front-ends, reversing decisions made ssome time ago. ADO is obsolete, having been replaced by ADO.NET. Seen from the perspective of an ACCESS developer i can inmagine this decission as DAO is superior in perfomance However this topic is about a VB.Net developer interacting with a ACCESS database , and from that point seen i can not find a valid reasson to use Access at all as a database with anny engine wether it is DAO or ADO.Net This is confusing me : The design structure of Access for dealing with databases is so complete and therefore complex, that I believe that there haven't been any .NET efforts made to work with it yet. It may be several years before Microsoft builds any .NET capability into Access. Until then, DAO is the faster and more complete method of dealing with JET data. As far as i know the versions of Access starting from 2003 use the MSDE engine or SQL express so i see Microsoft never upgrade these engines to .Net as there are already sql 2005 engines out there wich already support the .Net framework and languages I guess time will fase out the Jet engine ......... Or am i missing something here ? Michel "Arvin Meyer [MVP]" schreef in bericht ... "Michel Posseth [MCP]" wrote in message ... http://msdn2.microsoft.com/en-us/library/ms810810.aspx scroll to the bottom to see that DAO is officially declared Obsolete ( a long time ago ) note: that this paper was released the first time in January 2002 but it was known to the programming comunity long time before that At our last MVP Summit in Seattle, we were specifically told by Microsoft that DAO is the preferred method of dealing with JET and SQL-Server databases from Access front-ends, reversing decisions made ssome time ago. ADO is obsolete, having been replaced by ADO.NET. The design structure of Access for dealing with databases is so complete and therefore complex, that I believe that there haven't been any .NET efforts made to work with it yet. It may be several years before Microsoft builds any .NET capability into Access. Until then, DAO is the faster and more complete method of dealing with JET data. -- Arvin Meyer, MCP, MVP http://www.datastrat.com http://www.mvps.org/access http://www.accessmvp.com |
#15
|
|||
|
|||
Opening Access db via DAO in vb.net
"Ed Metcalfe" schreef in bericht ... "Michel Posseth [MCP]" wrote in message ... Recomended by who ? as MS did not even bother to develop a 64 bit Jet oledb driver for Access this means that even ADO.Net can`t work with Access so in my opinion MS doesn`t want you to use Access at all in newly to develop products . that is probably also the reasson why in all study materials , examples etc etc only connections to one of the SQL family`s is shown ( wich by the way do have 64 bit equivalants ) By the vast majority of people I speak to who are still developing solutions in Microsoft Access using the Jet database engine. Regardless of whether they should be there are still a lot of them and the overall performance of ADO when working with Jet is, frankly, abysmal. Here comes our difference in perspective , You talk as a ACCESS developer , a person who writes solutions completely in ACCESS , throws in some Access forms and or VBA I see it from the perspective of a software developer , i just use a DB as a storage DAO `s perfomance is superb on ACCESS , as it is a specialized engine optimized for this database However my question is should you use a long time ago fased out technology in a newly developed product ? Probably not, however I never stated an opinion for or against Jet as a suitable solution for John's application. I presume he has his reasons for choosing it over more current technologies. And if we are talking about perfomance lets put the cards right and compares against SQL server CE wich is the substitute for a Access database in .Net I'm sure you're right. Nevertheless DAO is, in most cases, *much* faster when working with Jet than ADO. As John is using an MDB file I would strongly recommend he tries DAO as well as ADO as, in my experience, it may make the difference between a usable and unusable system. Ed Metcalfe. I have done some comparisations in the past and posted the results in these newsgroups , ( i was once a sceptic to ) between DAO interop , legacy ADO interop and ADO.Net and indeed DAO is much faster untill you do subsequent requests on the same result sets, the caching mechanism of ADO then kicks in however the overall winner is DAO . However as a VS developer you have the option to ditch ACCESS completely as a storage engine , and use native .Net technology and if you take the lowest version of the native SQL engine ( the everywhere edition a.k. SQL CE ) the cards are shufled in a different way . And you get a lot of extra advantages to call a few deployability ( xcopy deployment ) , Scalability ( to express or higher depending the needs ) There was only one thing that holded me with ACCESS in the past as a storge db in my VS projects , and this was the security of our data , in the company i worked for at that moment we owned the data that was distributed to the end users , so we had to lock the database file this was only possible with ACCESS at that moment with a custom workgroup file . However with SQL server everywhere edition you can protect your data in a simular way so i cannot inmagine why a developer would want to use a ACCESS database for storage of his data in a VS project . But i am always openminded and eager to learn so maybe he can surprise me with a good reasson ,,, and did i not provide him with the code he needed to open the db with DAO in VB.Net ? . Although i would not recomend it to use ACCESS this way ( or even at all as a storage db in a VS.Net project ) that wasn`t his question :-) . I just wanted to point out the more elegant solutions for data storage that are availlable right now for VS.Net developers I enjoyed this discussion , nice thingy from these multi group postings is that you encounter people with a totally different view of things, and you might learn something new . regards Michel Posseth |
#16
|
|||
|
|||
Opening Access db via DAO in vb.net
Well after thoroughly thinking about this question , the answer seems
You don`t :-) Or maybe we are both missing something here Regards Michel "Norman Yuan" schreef in bericht ... With all other replies being post, I am just wondering: why on the earth do you need to use DAO in .NET? "John" wrote in message ... Hi In my vb.net app I am trying to open a db via DAO as below; Imports dao Dim dbSynch As dao.Database dbSynch = DBEngine(0).OpenDatabase("C:\MYDB.MDB") The problem is that on the last line I am getting the error 'DBEngine' is a type and cannot be used as an expression. What am I doing wrong? Many Thanks Regards |
#17
|
|||
|
|||
Opening Access db via DAO in vb.net
"Michel Posseth [MCP]" wrote in
: snip DAO is still the recommended method for accessing data in Microsoft Access databases if you are using the Jet database engine. /snip Recomended by who ? as MS did not even bother to develop a 64 bit Jet oledb driver for Access this means that even ADO.Net can`t work with Access so in my opinion MS doesn`t want you to use Access at all in newly to develop products . that is probably also the reasson why in all study materials , examples etc etc only connections to one of the SQL family`s is shown ( wich by the way do have 64 bit equivalants ) Agreed - Acecss is the way of the Dodo in terms of application development. Microsoft has pretty much pigeon holed it into a pure personal desktop database now. -- (Do not e-mail) |
#18
|
|||
|
|||
Opening Access db via DAO in vb.net
"Ed Metcalfe" wrote in message ... "Arvin Meyer [MVP]" wrote in message ... At our last MVP Summit in Seattle, we were specifically told by Microsoft that DAO is the preferred method of dealing with JET and SQL-Server databases from Access front-ends, reversing decisions made ssome time ago. ADO is obsolete, having been replaced by ADO.NET. Is this information published on the Microsoft website anywhere? The most recent article I could find was this: http://support.microsoft.com/kb/225048 As you can see, that article hasn't been updated in over 4 years. There may be some info on the Access Team blog: http://blogs.msdn.com/access/ I did a cursory search using DAO vs ADO and found: http://blogs.msdn.com/access/search....DAO+vs+ADO&p=1 which seems to mention several postings by the MS-Access PMs on using DAO in Access 2007. Sorry I did not do further research, but you're welcome to. -- Arvin Meyer, MCP, MVP http://www.datastrat.com http://www.mvps.org/access http://www.accessmvp.com |
#19
|
|||
|
|||
Opening Access db via DAO in vb.net
Actually, you are missing quite a lot. Yes this is definitely from the
perspective of an Access developer. You must realize that the question concerned an Access, or more accurately a JET database. JET, has always been the default engine for Access since version 2.0. Access can however use any other DBMS that has connectivity, including all Microsoft engines, and many, if not most, non-Microsoft engines. .NET is not an engine, rather it is a code base which is not as yet be fully integrated with other, especially older, technologies, but usually is can use those technologies. COM is one example, DAO, another. Contrary to your supposition, Microsoft has upgraded the JET engine with the release of Access 2007, and is currently upgrading it for the next release. More, I cannot say because of NDA restrictions. I will not discuss whether or not to use Access as a front-end, or JET as a back-end because we both have certain prejudices. I will say, that more Access databases are in existence than all other databases combined, and it has been that way for 15 years. I don't argue with that kind of success, I benefit from it. -- Arvin Meyer, MCP, MVP http://www.datastrat.com http://www.mvps.org/access http://www.accessmvp.com "Michel Posseth [MCP]" wrote in message ... At our last MVP Summit in Seattle, we were specifically told by Microsoft that DAO is the preferred method of dealing with JET and SQL-Server databases from Access front-ends, reversing decisions made ssome time ago. ADO is obsolete, having been replaced by ADO.NET. Seen from the perspective of an ACCESS developer i can inmagine this decission as DAO is superior in perfomance However this topic is about a VB.Net developer interacting with a ACCESS database , and from that point seen i can not find a valid reasson to use Access at all as a database with anny engine wether it is DAO or ADO.Net This is confusing me : The design structure of Access for dealing with databases is so complete and therefore complex, that I believe that there haven't been any .NET efforts made to work with it yet. It may be several years before Microsoft builds any .NET capability into Access. Until then, DAO is the faster and more complete method of dealing with JET data. As far as i know the versions of Access starting from 2003 use the MSDE engine or SQL express so i see Microsoft never upgrade these engines to .Net as there are already sql 2005 engines out there wich already support the .Net framework and languages I guess time will fase out the Jet engine ......... Or am i missing something here ? Michel "Arvin Meyer [MVP]" schreef in bericht ... "Michel Posseth [MCP]" wrote in message ... http://msdn2.microsoft.com/en-us/library/ms810810.aspx scroll to the bottom to see that DAO is officially declared Obsolete ( a long time ago ) note: that this paper was released the first time in January 2002 but it was known to the programming comunity long time before that At our last MVP Summit in Seattle, we were specifically told by Microsoft that DAO is the preferred method of dealing with JET and SQL-Server databases from Access front-ends, reversing decisions made ssome time ago. ADO is obsolete, having been replaced by ADO.NET. The design structure of Access for dealing with databases is so complete and therefore complex, that I believe that there haven't been any .NET efforts made to work with it yet. It may be several years before Microsoft builds any .NET capability into Access. Until then, DAO is the faster and more complete method of dealing with JET data. -- Arvin Meyer, MCP, MVP http://www.datastrat.com http://www.mvps.org/access http://www.accessmvp.com |
#20
|
|||
|
|||
Opening Access db via DAO in vb.net
"Michel Posseth [MCP]" wrote in message
... Here comes our difference in perspective , You talk as a ACCESS developer , a person who writes solutions completely in ACCESS , throws in some Access forms and or VBA I see it from the perspective of a software developer , i just use a DB as a storage That, is a huge difference. I can't speak for Ed, but I can tell you that all I do is write database solutions. Access is not my only tool, but I must say, that it is uniquely appropriate for database application construction, if one is building those applications to run on a workstation. I've been developing databases since 1981, and Access databases since 1992. I've made living developing databases since 1994. I've been an MVP in Access since 2000, and also some security related technologies, holding dual MVP status for 1 year (that's no longer possible). JET, is definitely not appropriate for all uses. Neither is any database engine. I do prefer Microsoft engines though, because of the really great support that Microsoft gives its developer community. That does not mean that I don't use other technologies, but it does mean that if I'm busy. I'll sooner turn down jobs that don't use technologies that I can't give my clients what I feel is the best value for their money. For instance, I refer all jobs where the Internet may offer a better alternative than the LAN to other developers. Most of my work is not enterprise wide, although I do lots of work for government and Fortune 500 clients. For enterprise wide solutions, Access in not suited for any but the most lightly used applications. Most of the enterprise apps I see use VB, Java, or .NET solutions which are not particularly interesting to me because they require larger teams to build successfully. -- Arvin Meyer, MCP, MVP http://www.datastrat.com http://www.mvps.org/access http://www.accessmvp.com |
Thread Tools | |
Display Modes | |
|
|