MSDE 2000a Deployment Issues

I need to deploy MSDE 2000a with a custom app built in VB6. I found the
setup package to add MSDE 1.0 through the Package & Deployment Wizard, but
the link I found for MSDE 2000 goes to the same article as 1.0. I've also
seen a lot of info on using merge modules to deploy MSDE 2000, but I'm
clueless about them. What is the best (and hopefully easiest) way to deploy
MSDE 2000 with a custom app built with VB6 using the Package & Deployment
Wizard? Any help would be greatly appreciated.
My advice is don't.
Package the setup program from MS, configure the setup.ini file the way you
want it and get the user to run it. Every other option seems to end up in
pain at present. Much better story coming for SQL Express.
HTH,
Greg Low [MVP]
MSDE Manager SQL Tools
www.whitebearconsulting.com
"pbb" <pbb@.discussions.microsoft.com> wrote in message
news:DDFFD02B-301D-4273-B32B-D6CCFAB50A76@.microsoft.com...
>I need to deploy MSDE 2000a with a custom app built in VB6. I found the
> setup package to add MSDE 1.0 through the Package & Deployment Wizard, but
> the link I found for MSDE 2000 goes to the same article as 1.0. I've also
> seen a lot of info on using merge modules to deploy MSDE 2000, but I'm
> clueless about them. What is the best (and hopefully easiest) way to
> deploy
> MSDE 2000 with a custom app built with VB6 using the Package & Deployment
> Wizard? Any help would be greatly appreciated.
|||Okay, so it sounds like what you're saying is that it's best to include 2
setup programs? First have the user run the setup.exe that comes with MSDE
(with the customized ini file), and then have them run the setup package for
the custom app?
"Greg Low [MVP]" wrote:

> My advice is don't.
> Package the setup program from MS, configure the setup.ini file the way you
> want it and get the user to run it. Every other option seems to end up in
> pain at present. Much better story coming for SQL Express.
> HTH,
> --
> Greg Low [MVP]
> MSDE Manager SQL Tools
> www.whitebearconsulting.com
> "pbb" <pbb@.discussions.microsoft.com> wrote in message
> news:DDFFD02B-301D-4273-B32B-D6CCFAB50A76@.microsoft.com...
>
>
|||Yep
"pbb" <pbb@.discussions.microsoft.com> wrote in message
news:4203C438-9A56-48F0-B36D-22793F26F4AD@.microsoft.com...[vbcol=seagreen]
> Okay, so it sounds like what you're saying is that it's best to include 2
> setup programs? First have the user run the setup.exe that comes with
> MSDE
> (with the customized ini file), and then have them run the setup package
> for
> the custom app?
> "Greg Low [MVP]" wrote:

msdb or file system

When I log into Integrated Services on my SQL server, I see [Stored Package] -- File System and MSDB.

When I deploy/import my SSIS packages which should it go under? Is there a difference and if so what the difference?

thanks

HAHAHA! You asked the exact same question as someone else and within something like two hours.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2008865&SiteID=1

Since that question is unanswered, here's the deal.

Where you ultimately choose to store your packages, is up to you. They each do the same thing, but with some differences.

With File System storage, you can simply map a network drive to the server and just copy your packages over to the server. With SQL Server, you need to import into MSDB.

Some like to use File System, but to me, the permissions are harder to work with. Because SSIS does not save passwords, you'll have to use a configuration file to specify passwords for your connection managers. Either that, or you'll have to use EncryptSensitiveWithPassword and then specify a decryption password with the command line.

SQL Server has the same problems unless you tell it to use "SQL Server Roles and Storage" when importing. This is what I choose to use. Access is controlled via SQL Server roles/security.

Search this forum for other ideas regarding file system versus MSDB.|||

LOL

thanks, I'm not a big fan of using the file system for much and due to the permissions within the tool then going through the act of congress to get permissions setup on a network drive to use, isn't worth the hassle.

It would take me longer to get that setup (just from the network side) then it would for me to create a package, test it, import it and roll it out to production and create 10 more.

So I think I'll go the MSDB route.

|||More information:

http://blogs.conchango.com/jamiethomson/archive/2006/02/20/SSIS_3A00_-Deploy-to-file-system-or-SQL-Server.aspx

http://www.sqljunkies.com/WebLog/knight_reign/archive/2005/05/05/13523.aspx|||

thanks, I was just reading the sqljunkies.com one actually.

So far I'm not finding a clear cut answer, I guess it really depends on the person deploying the packages.

its kind of like, what language is better C# or VB.NET? no clear answer, its developer preference.

thanks again