Error 208 Failed to open new connection

Your help and a reboot put us back in business. Thanks.
Regards,
Jamie
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> It could be that your 32 bit drivers have not been installed correctly, in
> which case you would have other issues with 32 bit application.
> It may be worthwhile running the DTA clean up script
> http://support.microsoft.com/kb/899634/
> John
> "thejamie" wrote:
Not sure what I contributed! Did you find out what was missing?
John
"thejamie" wrote:
[vbcol=seagreen]
> Your help and a reboot put us back in business. Thanks.
> --
> Regards,
> Jamie
>
> "John Bell" wrote:
|||I think you are right about the red herring. There is definitely an issue
here due to the 64 bit Enterprise server running SQL 2000 Std... we can't get
DTS to run the older OLE Excel when it is used in a package. I suspect but
did not isolate the cause but suspect the security is tighter on the 64 bit
servers. The 64 bit server has other surprises - if you set up a new one the
64 bit servers that are already in the network quarantine it until after they
are rebooted. The 64 bit machine requires that security be altered on the
temp directory profile of the service account if you want the SQLAgent to
kick off email for anyone except the admin accounts (this includes sa).
All this - running a Std 2000 SQL package. We must upgrade to SQL 2005 64
bit. As far as the DTS is concerned, I don't think there is a fix.
Regards,
Jamie
"John Bell" wrote:
[vbcol=seagreen]
> Not sure what I contributed! Did you find out what was missing?
> John
> "thejamie" wrote:
|||Hi
Have you tried creating a new package with an excel data source?
Moving to SQL 2005 you should be using the benefits of SSIS.
John
"thejamie" wrote:
[vbcol=seagreen]
> I think you are right about the red herring. There is definitely an issue
> here due to the 64 bit Enterprise server running SQL 2000 Std... we can't get
> DTS to run the older OLE Excel when it is used in a package. I suspect but
> did not isolate the cause but suspect the security is tighter on the 64 bit
> servers. The 64 bit server has other surprises - if you set up a new one the
> 64 bit servers that are already in the network quarantine it until after they
> are rebooted. The 64 bit machine requires that security be altered on the
> temp directory profile of the service account if you want the SQLAgent to
> kick off email for anyone except the admin accounts (this includes sa).
> All this - running a Std 2000 SQL package. We must upgrade to SQL 2005 64
> bit. As far as the DTS is concerned, I don't think there is a fix.
> --
> Regards,
> Jamie
>
> "John Bell" wrote:
|||The 208 message is a red-herring. That was as good an answer as I might
expect. As far as running a 32 bit SQL 2000 Std version on a 64 bit
Enterprise 2003 R2, the jury is still out but we have stablized and the
system appears solid. I hate to say it for sure because that'll jinx it.
Around here it is sometimes hard to distinguish what is a programming error
on our part versus what is bad data causing failures internally. It is
extremely difficult to predict what surprises will come through on our EDI
system. Other than the Excel blip - which might be something as simple as
group policy, the system in general, including linked servers, MCI
connections, routers, nic cards, jobs, dts packages, logins, moving
databases, tcp/ip aliasing... this part has been relatively smooth. There
were some rough spots that were only resolved by server reboots. As my
supervisor stated returning from the warehouse "No bullet holes... that's a
good thing."
I've yet to try to put together an Excel package with SSIS.
Regards,
Jamie
"John Bell" wrote:
[vbcol=seagreen]
> Not sure what I contributed! Did you find out what was missing?
> John
> "thejamie" wrote:
|||I'm actually still stumbling with one of the issues.
Example:
A query that uses an absolute reference to a server over a linked server...
Select * from servera.database1.dbo.table where mycolumn='xyz'
will pretty much give instant results whereas
Declare @.var varchar(25)
set @.var='xyz'
select * from servera.database1.dbo.table where mycolumn=@.var
takes forever and ever and there is no error message - just a huge delay for
the data to relay. I tried creating a role with permission to
(select,update,delete,insert,execute,references) all tables, all views, all
procs and all functions and adding the domain users to the role. This does
not work to make the query any faster.
The example above takes about 8 minutes to process with the variable less
than one second to process.
What is the difference?
Regards,
Jamie
"John Bell" wrote:
[vbcol=seagreen]
> Not sure what I contributed! Did you find out what was missing?
> John
> "thejamie" wrote:
|||Here is the answer to the Error 208 failed to open connection
A DTS package can be saved on the 64-bit server, and a DTS package can be
run against a SQL Server 2000 (64-bit) dataset, but the package must run from
a 32-bit machine that is set up with SQL Server 2000 tools.
http://www.sqlservercentral.com/articles/Miscellaneous/overviewof64bitsql/1166/
Regards,
Jamie
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> Have you tried creating a new package with an excel data source?
> Moving to SQL 2005 you should be using the benefits of SSIS.
> John
> "thejamie" wrote:
|||Hi
This may be something to do with where the filter is applied, check out the
query plans to see the difference. To get around this you could use EXEC or
OPENQUERY and concatenate the value
John
"thejamie" wrote:
[vbcol=seagreen]
> I'm actually still stumbling with one of the issues.
> Example:
> A query that uses an absolute reference to a server over a linked server...
> Select * from servera.database1.dbo.table where mycolumn='xyz'
> will pretty much give instant results whereas
> Declare @.var varchar(25)
> set @.var='xyz'
> select * from servera.database1.dbo.table where mycolumn=@.var
> takes forever and ever and there is no error message - just a huge delay for
> the data to relay. I tried creating a role with permission to
> (select,update,delete,insert,execute,references) all tables, all views, all
> procs and all functions and adding the domain users to the role. This does
> not work to make the query any faster.
> The example above takes about 8 minutes to process with the variable less
> than one second to process.
> What is the difference?
> --
> Regards,
> Jamie
>
> "John Bell" wrote: