Tuesday, March 6, 2012

About the new MSDE

I am in the process of downgrading an MSDE database to a Jet (Access)
database for the following reason:
1. Size: Deployment of an MSDE database engine is inflating my distribution
file (Setup.exe) over 20 Megs! With an Access database this number is ZERO
because all the infrastructure to access my Access database is already
included on the .Net framework.
2. Setup: MSDE is complex to setup, you pretty much have to use an installer
to accomplish this where with an Access database you just copy the mdb file
and you are done.
3. Maintainability: With MSDE I will have to issue independent patches for
fixes to the MSDE engine where with an Access database, fixes are included
in the .Net framework service pack.
4. Portability: With a .Net application and an Access database, I could copy
my program and the database into a USB memory stick or a writable CD and
actually run my application from there, this is a big deal for me as people
can carry my application on their USB keychain and use it any time in any
computer. This is not possible with MSDE.
Number 1 & 4 are biggies for me. The think that really bothers me is that my
application already runs online against an SQL server database so using an
MSDE to have the database running locally makes it EXTREMELY simple for me
because I can use the exact same SQL server database directly were with
access I will have create a new database, rewrite my stored procedure logic
and maintain 2 database (online SQL server and local Access database).
If the new version of MSDE is basically the same thing as the old MSDE
except that it has more features then I guess I am doomed and I will have to
use an Access database.
Any comment regarding my predicament are very much appreciated. Thanks.
hi Rene,
Rene wrote:
> I am in the process of downgrading an MSDE database to a Jet (Access)
> database for the following reason:
> 1. Size: Deployment of an MSDE database engine is inflating my
> distribution file (Setup.exe) over 20 Megs! With an Access database
> this number is ZERO because all the infrastructure to access my
> Access database is already included on the .Net framework.
actually 43mb :D
http://www.microsoft.com/downloads/d...displaylang=en

> 2. Setup: MSDE is complex to setup, you pretty much have to use an
> installer to accomplish this where with an Access database you just
> copy the mdb file and you are done.
right, but the installer can really be a little companion tool that provides
an UI to the setup.exe boostrap installer to gather all required parameters
and user options, then shells to setup.exe... but ok, it's more complex than
mdb file copy..

> 3. Maintainability: With MSDE I will have to issue independent
> patches for fixes to the MSDE engine where with an Access database,
> fixes are included in the .Net framework service pack.
AFAIK .Net FWK does not contain MDAC... and MDAC itself, up to v. 2.6 no
longer provides the JET components, so you manually have to install/upgrade
it.. ok, actual Win OS releases already have it as part of core
installation, but you have to manually upgrade JET "things"..

> 4. Portability: With a .Net application and an Access database, I
> could copy my program and the database into a USB memory stick or a
> writable CD and actually run my application from there, this is a big
> deal for me as people can carry my application on their USB keychain
> and use it any time in any computer. This is not possible with MSDE.
you can do sort of this with MSDE too... your application must attach the
dbs residing on the USB key at application start up, and obviously detach
them before key removal (or the dbs will be marked as suspect).. this is not
the very best solution for SQL Server database, both for performance and
security reasons, but it can be done... and, of course, even if this is an
MSDE default setting, set the autoclose db option :D
just a side note... I recently bought an USB key and read something about
100.000 writes warranty...
well, I really do not know how long does it takes for SQL Server/MSDE (but
even JET) to exceed this value, but I'd expect not that much time... so
stay tuned :D

> Number 1 & 4 are biggies for me. The think that really bothers me is
> that my application already runs online against an SQL server
> database so using an MSDE to have the database running locally makes
> it EXTREMELY simple for me because I can use the exact same SQL
> server database directly were with access I will have create a new
> database, rewrite my stored procedure logic and maintain 2 database
> (online SQL server and local Access database).
> If the new version of MSDE is basically the same thing as the old MSDE
> except that it has more features then I guess I am doomed and I will
> have to use an Access database.
SQLExpress will support (single user) User Instances,
http://tinyurl.com/bm3to , that combined with .Net XCopy deployment can
perhaps get your point...
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.15.0 - DbaMgr ver 0.60.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||Hi Andrea:

> AFAIK .Net FWK does not contain MDAC... and MDAC itself, up to v. 2.6 no
> longer provides the JET components, so you manually have to
> install/upgrade it.. ok, actual Win OS releases already have it as part of
> core installation, but you have to manually upgrade JET "things"..
I know for sure of two things about this Access db trip. The first one is
that I am using ADO.Net as my data object layer and the second one, that I
am using the Microsoft.Jet.OLEDB.4.0 provider and as a result the Jet
engine.
I did some research on the web and found out that it looks like the
"smarties" form Microsoft are retiring the Jet engine and we now can all
look forward to having to distribute a 70 Megabytes SQL express to go with
our little 2 meg applications.
It also looks like the Jet engine is indeed distributed with the OS (after
Win 2000), I am wondering if this will stop happening with new OS versions.
For earlier version of Windows I guess I will have to distribute the MDAC
2.6 and pray that that comes with Jet 4.0
Frankly, I think this is absolutely retarded, Access/Jet were perfect for
your average database application and it should be fully supported and
distribute on the .Net. This is REALLY stupid.
|||> Frankly, I think this is absolutely retarded, Access/Jet were perfect for
> your average database application and it should be fully supported and
> distribute on the .Net. This is REALLY stupid.
Luckily it seems both Access and Jet will survive.
Check this:
http://blogs.msdn.com/access/
Jesper
|||I don't know where you did your research on the web, but it is
absolutely inaccurate. Access/Jet will continue to be supported for
exactly the scenario you describe, and is being enhanced for Office
12, which is now in limited technical beta.
Bear in mind that Access/Jet is not recommended for Web apps or even
heavy-duty intranet apps, and you should be fine.
--Mary
On Fri, 18 Nov 2005 15:19:43 -0600, "Rene" <nospam@.nospam.com> wrote:

>Hi Andrea:
>
>I know for sure of two things about this Access db trip. The first one is
>that I am using ADO.Net as my data object layer and the second one, that I
>am using the Microsoft.Jet.OLEDB.4.0 provider and as a result the Jet
>engine.
>I did some research on the web and found out that it looks like the
>"smarties" form Microsoft are retiring the Jet engine and we now can all
>look forward to having to distribute a 70 Megabytes SQL express to go with
>our little 2 meg applications.
>It also looks like the Jet engine is indeed distributed with the OS (after
>Win 2000), I am wondering if this will stop happening with new OS versions.
>For earlier version of Windows I guess I will have to distribute the MDAC
>2.6 and pray that that comes with Jet 4.0
>Frankly, I think this is absolutely retarded, Access/Jet were perfect for
>your average database application and it should be fully supported and
>distribute on the .Net. This is REALLY stupid.
>

No comments:

Post a Comment