Re: "Best Practices" way to distribute MSDE
From: Andrea Montanari (andrea.sqlDMO_at_virgilio.it)
Date: 07/09/04
- Next message: Andrea Montanari: "Re: backing up using sql-dmo"
- Previous message: dev_kh: "Re: backing up using sql-dmo"
- In reply to: Ian Boyd: "Re: "Best Practices" way to distribute MSDE"
- Next in thread: Ian Boyd: "Re: "Best Practices" way to distribute MSDE"
- Reply: Ian Boyd: "Re: "Best Practices" way to distribute MSDE"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 9 Jul 2004 17:08:43 +0200
hi Ian,
"Ian Boyd" <admin@SWIFTPA.NET> ha scritto nel messaggio
news:e1pXkyVZEHA.2216@TK2MSFTNGP10.phx.gbl...
> Now is there any Microsoft document that describes this typical situation
of
> a client's computer was re-installed, and they need their data back...
>
> What is the best practice to do this?
>
> Ways to put a database into a server:
> Attach my empty db
> Restore my empty db
> Run scripts to create my empty db
> Restore a users's selected backup.
> Attach a users db from a previous install.
as MSDE is distributed without management tools but oSql.Exe, the guidlines
I've found are in
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q325003..
in my understanding, you, as an ISV, are supposed to provide all the
functionnalities to support and manage your database(s) inside your
application(s) and/or with companion tools (thrid party or home built)
so you have to provide backup/restore functionalities, login/users
management and so on...
as regards database(s) creation, I do personally provides Transact-SQL
scripts, but attaching a shipped .mdf + .ldf solution is viable too, and is
often recommended as the simplest solution, but I do personally don't like
it, perhaps for a "purist" point of view...
anyway... for the sake of simplicity, you can use the method you better
like, as, for instance, Red-Gate new Packager tool
(http://www.red-gate.com/sql/sql_packager.htm), which provides a single file
installer for your database(s)...
> Is there a concensus on an interface, API, and routines to perform these
> things are automatically as possible?
for dayly house-keeping I do usually provide scripted job for database
backup, that rely on the SQL Server Agent, but my apps all feature (not
scheduled) backup functionalities, as long as login/user management..
database restore shoul'd usually not be a daly operation [=;-D ] , but is
provided as well... one shot operation...
again, personally I choose SQL-DMO API becouse I already provided it's
dependencies for my companion database general management tool, but
ADO/ADO.Net are good as well.. it all depends on your needs/API
skill/preferred method....
>
> Remember, if i'm supposed to be using MSDE now instead of Jet: Jet was
very
> easy for the client to backup and restore. They copied the file when they
> wanted a backup, and they put it into the folder when they wanted to
> restore.
>
actually you can even choose this solution, as long as your database all
have the 'Auto close' property set... this option will actually close (and
free) the physical database and transaction log files on the file system, so
that file copy operation (not SQL Server backup!) can be performed.. please
keep in mind connection pool time, which usually requires about 1 minute to
effectively close...
but, again... my personala advice is to perform dayly house-keeping actions
withour user's intervention.. that's to say: do what your users usually
skip... automatically backup their data ...
one draw back... SQLExpress, the replacement for MSDE in the SQL Server 2005
code base, will remove SQL Server Agent from the SKU, so keep in mind this
for the future.. personally I've still have to choose a scheduled
alternative, but I'll provide it for sure.
remember, you are supposed to provide all the manage/support
functionnalities
> What is the MSDE equivalent procedures to accomplish the same task as
> seamlessly for the end user without any vendor intervention or
hand-holding?
as MSDE is NOT Jet, you have a lot of extra features at a resonably price
[=;-D], but you have to take some new sagacity in your work...
nowdays, all our users do have some Access skill [potentially dangerous
=;-D ], so you shoul'd even train your users a little more, but this is
another story...
> What are the "Best Practices" way to distribute MSDE?
Microsoft provides ton of information as
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql2k/html/sql_embeddingmsde.asp
http://www.microsoft.com/sql/techinfo/administration/2000/security/isvswithmsdes.asp
http://www.microsoft.com/sql/msde/techinfo/MSDEintegration.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/distsql/distsql_7b91.asp
....
personally I do provide a separate setup for MSDE, with a home built user
interface that takes care and handles all required parameter to then shell
to the setup.exe boostrap installer...
-- Andrea Montanari (Microsoft MVP - SQL Server) http://www.asql.biz/DbaMgr.shtm http://italy.mvps.org DbaMgr2k ver 0.8.0 - DbaMgr ver 0.54.0 (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual interface) --------- remove DMO to reply
- Next message: Andrea Montanari: "Re: backing up using sql-dmo"
- Previous message: dev_kh: "Re: backing up using sql-dmo"
- In reply to: Ian Boyd: "Re: "Best Practices" way to distribute MSDE"
- Next in thread: Ian Boyd: "Re: "Best Practices" way to distribute MSDE"
- Reply: Ian Boyd: "Re: "Best Practices" way to distribute MSDE"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
