MSDE and DTS packages

Hi all
I am new to the msde and have worked with SQL for a little while. I have developed my database on my SQL server and now have transfered it to MSDE with only one problem.
I have exported the dts package to a text file, but when I import it into MSDE there is nothing there.
My question is can I (and how) create a DTS package through vbscript or osql? I have looked in MSDN and found the dtswiz with command line switchs, but I can not find an example using a text file. I unbderstand that there are a few more switches to tell
it the delimitation.
Any help would be very appreciated.
Thanks for your help in advance.
I'm guessing you want to import dts packages into MSDE (if not my
appologies).
you can save the package as a structured storage file and use a little vb
app to load the package in memory and then save it to the msde using
SaveToSQLServer function of the package class ?
If you have a SQL Server then you can also use enterprise manager to simply
save the DTS packes directly to your msde instance.
Hope this helps.
Ranjeet.
"whiggins" <anonymous@.discussions.microsoft.com> wrote in message
news:8A03C082-9B78-4106-83EF-F2DC7FBD65E6@.microsoft.com...
> Hi all
> I am new to the msde and have worked with SQL for a little while. I have
developed my database on my SQL server and now have transfered it to MSDE
with only one problem.
> I have exported the dts package to a text file, but when I import it into
MSDE there is nothing there.
> My question is can I (and how) create a DTS package through vbscript or
osql? I have looked in MSDN and found the dtswiz with command line switchs,
but I can not find an example using a text file. I unbderstand that there
are a few more switches to tell it the delimitation.
> Any help would be very appreciated.
> Thanks for your help in advance.

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