Michel Posseth [MCP]
2/3/2008 6:59:00 PM
"Ed Metcalfe" <edmetcalfe@hotmail.com> schreef in bericht
news:%230miUpoZIHA.5612@TK2MSFTNGP06.phx.gbl...
>
> "Michel Posseth [MCP]" <MSDN@posseth.com> wrote in message
> news:u3sd55lZIHA.4808@TK2MSFTNGP05.phx.gbl...
>> 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