Thursday, March 8, 2012

Absolut Noob here.

Hi all,
I've been working with SQL Server 2000 for most of the development I do but
now we're looking to build a small database that can run locally on the
client machine along with the application with which it will be distributed.
The following are my questions regarding this.
What do I need to do to properly create a database that will be accessible
by MSDE on a client machine?What is the best way to access it once it's
there (ie creating an ODBC System DSN)?
Can I do all of the database design work in SQL Server 2000?
Thanks in advance for the help.
Regards,
Daniel Hobert
hi Daniel,
Daniel Hobert wrote:
> Hi all,
> I've been working with SQL Server 2000 for most of the development I
> do but now we're looking to build a small database that can run
> locally on the client machine along with the application with which
> it will be distributed.
as you are used to SQL Server, MSDE is the same engine (with some
limitations) and all you know about SQL Server is valid for MSDE as long as
you do not hit it's limitations...

> The following are my questions regarding this.
> What do I need to do to properly create a database that will be
> accessible by MSDE on a client machine?
you have all the SQL Server possibilities available, from detach-attach,
backup/restore and script/exec...
I am an estimator of the latter, where you get the DDL code from your source
control system to create the user's database(s) your application need, where
you inherit from destination model database all the available settings as
long as included objects/users...
just for your note, the best article I read about such a kind of
installation, including database schema support is
http://msdn.microsoft.com/msdnmag/is...einstaller/...

>What is the best way to access
> it once it's there (ie creating an ODBC System DSN)?
it really depends on your coding standard... personally I always use
DSN-less connections as ADO/Ado.Net support them very well...

> Can I do all of the database design work in SQL Server 2000?
yes and you should... MSDE is intended as a distribution platform and not as
a development paltform, with all of your dev tools available, like EM, Query
Analyzer, Index Tuning, Profiler and the like..
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.12.0 - DbaMgr ver 0.58.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,
Thanks a ton for the quick response and the link to the article .
Cheers,
Daniel
"Andrea Montanari" <andrea.sqlDMO@.virgilio.it> wrote in message
news:3h65jcFf4sp8U1@.individual.net...
> hi Daniel,
> Daniel Hobert wrote:
>
> as you are used to SQL Server, MSDE is the same engine (with some
> limitations) and all you know about SQL Server is valid for MSDE as long
> as you do not hit it's limitations...
>
> you have all the SQL Server possibilities available, from detach-attach,
> backup/restore and script/exec...
> I am an estimator of the latter, where you get the DDL code from your
> source control system to create the user's database(s) your application
> need, where you inherit from destination model database all the available
> settings as long as included objects/users...
> just for your note, the best article I read about such a kind of
> installation, including database schema support is
> http://msdn.microsoft.com/msdnmag/is...einstaller/...
>
> it really depends on your coding standard... personally I always use
> DSN-less connections as ADO/Ado.Net support them very well...
>
> yes and you should... MSDE is intended as a distribution platform and not
> as a development paltform, with all of your dev tools available, like EM,
> Query Analyzer, Index Tuning, Profiler and the like..
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
> DbaMgr2k ver 0.12.0 - DbaMgr ver 0.58.0
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> -- remove DMO to reply
>

No comments:

Post a Comment