(local) old db 4 sql server suddenly fails

Several DTS packages that use (local) as the server name
in the ms ole db providor for sql server suddenly broke.
They'd worked well for years. The existing connection
using (local) won't find the default instance on the
machine. A new connect using (local) works file. SQL
Server is 2k enterprise, sp 3a (818). OS is w2k
5.00.2195. Doesn't matter if the connection
authentication is W2k authenticated or standardHi,
It seems like the netbios name might have changed and connection still
resolving the (local) to old netbios.
Try using Select @.@.SERVERNAME and/or Select SERVERPROPERTY('servername')
thanks,
ashish
"bob b" <anonymous@.discussions.microsoft.com> wrote in message
news:6d6d01c3e69d$d7b3bac0$a401280a@.phx.gbl...

quote:

---

> Several DTS packages that use (local) as the server name
> in the ms ole db providor for sql server suddenly broke.
> They'd worked well for years. The existing connection
> using (local) won't find the default instance on the
> machine. A new connect using (local) works file. SQL
> Server is 2k enterprise, sp 3a (818). OS is w2k
> 5.00.2195. Doesn't matter if the connection
> authentication is W2k authenticated or standard

---

"standard packages" - where to store? Hints needed

Hi,

I would like to implement a kind of standard packages which can be used in all other processes and will be started using the variables.

But I do not know where to store these kind of packages in "best practise", because we

- would like to use them in Dev and in "Real" also without having to change something in the other processes

- we are storing the packages in the folders of the package store

and as far as I understood I would have to share the package store to all developers though that they would be able to do this?

Then I would better choose another folder with defined access rights I think...

Or would it be better to spend some time in developing a custom component?
But this component would work with recordsets rather than the standard data flow elemtents and therefor I would expect a leak of performance...
Or is it possible to do "trasnformation" from a packae to a custom component?

Thanks in advice!

cheers,
Markus

Personally, I think the best way all around is to store the common packages in SQL Server.

Unless you have a specific and valid reason to do otherwise, this is the best way because it handles a lot of the problems nicely like distribution, security and scheduling etc.

I don't understand how the latter questions relate to the common location question, sorry.

K

|||

i agree that sql server is the best place to store packages because it provides better security than the file system.

i believe that developer access should be controlled by a software configuration management system like visual studio team system.

"Renaming package" dialog

I created a new SSIS solution, right-clicked the default name "Package.dtsx" (under SSIS Packages), then renamed it. A dialog appears asking "Do you want to rename the package object as well"?

What are they referring to and what are the consequences of doing/not doing so?

Barkingdog

In Visual Studio you rename a file - the *.dtsx file. However, the SSIS package is an object in the file. So if you don't rename the object you could have a package file called MySuperPackage.dtsx containing a package object called MyOldPackage. Try saying no to the dialog once and check the name property of the package in the properties window - select the package by clicking in the background of the object expolorer.

Analysis Services has the same issue with cubes and other objects. The objects are defined in XML and have a name property - which can be different from the filename of the xml.

For this reason, when renaming packages, you should use the designer - do not just rename them in the file system.

Donald

"File System" vs MSDB packages?

Hello.
I was hoping to learn more about the differences between MSDB and "File System" Integration Services (IS) packages.

First, why do I have the option to choose?

Second, is there a way in T-SQL to query any information on File System packages? With the MSDB packages, I can query msdb.dbo.sysdtspackages90 .

Thanks for any info.

Kirk has a good post on the pros and cons of saving to file or SQL Server here: http://www.sqljunkies.com/WebLog/knight_reign/archive/2005/05/05/13523.aspx

There is no way, using T-SQL, to get information about file system packages. SQL Server does not know about such packages. The only slight caveat to this is that the file can be set to log to SQL Server - in which case there will be some info from the package in SQL Server - but SQL Server doesn't "know" about the package as such.

-Jamie|||Kirk has a good discussion

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

What type of info would you like from the package on disk?

Allan

"JFoushee@.discussions.microsoft.com"

wrote in message

news:c8e13f2e-2b59-4cb1-8b6a-5bb9e65b18b4@.discussions.microsoft.com:

> Hello.

> I was hoping to learn more about the differences between MSDB and "File

> System" Integration Services (IS) packages.

>

> First, why do I have the option to choose?

>

> Second, is there a way in T-SQL to query any information on File System

> packages? With the MSDB packages, I can query msdb.dbo.sysdtspackages90

> .

>

> Thanks for any info.|||What type of info would you like from the package on disk?

I was hoping to get directories and/or names of IS packages in the File System.

I think the "root" File System folder is stored as a Registry key.
However, the only place I found it was in HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\UserData\... , which suggests a per-user strategy. This doesn't make sense.|||There is no root package. The packages exist wherever you put them.

-Jamie|||I thoroughly agree there is no "root" package.
However, there is a root folder in Windows Explorer that corresponds to the File System folder in SSMS.
(In my case, C:\Program Files\Microsoft SQL Server\90\DTS\Packages)
This folder name is stored as a value in a Registry key.

When I add a folder or package to either
- C:\Program Files\Microsoft SQL Server\90\DTS\Packages in Windows Explorer
- the "Stored Packages"\"File System" folder in SSMS,
it will appear in the other.

I accept Jamie's answer that I cannot use TSQL to view the "File System" folder contents.

Wasn't sure if there some xp_cmdshell trickery that involves this Registry key, so that it would work for every SQL 2005 configuration. Probably not.

"Failed to acquire connection" when running a package from within another package.

I am receiving an error on my master package that executes a number of other packages. The individual packages work fine when executed by themselves. However, I am getting the following error when I attempt to execute it from another package:

Error: Failed to acquire connection "conneciton". Connection may not be configured correctly or you may not have the right permissions on this connection.

Thanks in advance for your help.

You could use this technique: http://blogs.conchango.com/jamiethomson/archive/2005/10/10/2253.aspx to help diagnose why your package is failing.

-Jamie

"Execute Package Utility has encountered a problem and needs to close"

I'm a SQL Server 2000 user trying to get my head around v2005, in particular the changes from DTS to Integration Services.

I've build a few packages in BIDS and they work fine there, but saving them to either the file system or MSDB locations and running them in Management Studio results in:

Execute Package Utility has encountered a problem and needs to close. We are sorry for the inconvenience.

If I click on the debug button, I get this:

An unhandled exception ('System.IO.FileNotFoundException') occurred in DTExecUI.exe [404].

I've searched the Internet and found a few people who has also experienced this, but not received any answers.

Is there a kind guru out there with some idea of what is going on? Preferably something that doesn't involve re-installing, because the database has already been configured for our Blackberry users and I can't re-do it now.
I have the same problem... have you got a soln yet?

Thanks|||I also get the same problem. Looking in the event log, it is appears it cant find a temp file...but that doesnt make sense to me. Any solutions?|||I had the same problem. It got fixed after applying SP2.