Fetch within a fetch

Is it possible to have fetch within a fetch? I am getting this error message "A cursor with the name 'crImgGrp' does not exist." So i separate the process into two stored procedures?

CREATE PROCEDURE TrigSendPreNewIMAlertP2
@.REID int

AS

Declare @.RRID int
Declare @.ITID int

Declare @.intIMEmail varchar(300)

Declare crReqRec cursor for
select RRID from RequestRecords where REID = @.REID and RRSTatus = 'IA' and APID is not null
open crReqRec
fetch next from crReqRec
into
@.RRID

Declare crImpGrp cursor for
select ITID from RequestRecords where RRID = @.RRID
open crImpGrp
fetch next from crImgGrp
into
@.ITID
while @.@.fetch_status = 0

EXEC TrigSendNewIMAlertP2 @.ITID

FETCH NEXT FROM crImpGrp
into
@.ITID

close crImpGrp
deallocate crImpGrp

while @.@.fetch_status = 0

FETCH NEXT FROM crReqRec
into
@.RRID

close crReqRec
deallocate crReqRec
GO... I'd re-think a different solution than what you want to do.

FeedFile Excel Connection Manager Concurrency Issue?

Hi,

RE. SSIS (v9.00.1399.00) FeedFile Excel Connection Manager Concurrency Issue

1. I have 15 completely separate SSIS Packages all of which use the FeedFile Excel Connection Manager to read data from completely separate Excel worksheets.

2. When I invoke, say, 5 of these Packages at the same time then one or more (at random) of them fail with the following error message:-

The AcquireConnection method call to the connection manager "FeedFile Excel Connection Manager" failed with error code 0xC0202009.

3. When I invoke the failed Packages again then they succeed.

So, do you know if there is:-

(a) a concurrency issue with the "FeedFile Excel Connection Manager" ?

(b) a read-only option (in the SSIS Package code) which needs to be specified to overcome file contention issues?

Additional Information about the FeedFile Excel Connection Manager:-

Connection String=Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\DoesNotNeedToExist.xls;Extended Properties="EXCEL 8.0;HDR=NO";

DelayValidation=True

ExcelFilePath= C:\DoesNotNeedToExist

RetainSameConnection=False

Note1. The actual Excel filename which is read is generated dynamically at run-time by a Script Task. This is why DelayValidation has been set to: True (Note. The file: "C:\DoesNotNeedToExist" does not actually physically exist.)

Note2. We have another SSIS Package which uses the FeedFile FlatFile Connection Manager. When we run this same Package concurrently (i.e. invoke it 5 times, at the same time, with different input files) then all 5 invocations succeed, which is what we would expect.

Thanks.

What is the "FeedFile Excel Connection Manager" as opposed to the regular Excel connection?

Is there no more detail? If running in BIDS, check the output winbdow, or if running unattanded, turn on logging.

I would expect there to be some additional error messages that go with 0xC0202009 error, which give the reason for this generic failure report.

|||

Sorry Darren, ignore the prefix FeedFile, it is the regular Excel connection.

I have not had a chance to look at this problem again but I will return to it later this week. I will let you know how I get on with trying to reproduce it in BIDevStudio etc.

From what I can gather though, there should be no limit to the number of separate SSIS Packages that can be run concurrently on a Server. Is this correct?

FC or ATA for LOG FILES?

I'm setting up a new DB and separating the log files to storage separate
from the data. The data will be on FC storage. Will the log files perform
optimally on FC or ATA?
Thanks in advance.
SBGFC as in FC-ATA where you're basically using cheap hardware?
I question your decision to put data and log files on such equipment in the
first place. However, as to the log files themselves, I suspect you could
put log files on an MFM drive, or an old 20MB removable platter and be fine
99.99% of the time. There just isn't that much I/O to the logs.
"SBG" <sbg@.thomasville.org> wrote in message
news:O1j$TY%23HIHA.4196@.TK2MSFTNGP04.phx.gbl...
> I'm setting up a new DB and separating the log files to storage separate
> from the data. The data will be on FC storage. Will the log files
> perform
> optimally on FC or ATA?
> Thanks in advance.
> SBG
>|||Oh, and .01% of the time is about 1 hour a year.
"Jay" <nospan@.nospam.org> wrote in message
news:eA$a3i%23HIHA.5544@.TK2MSFTNGP02.phx.gbl...
> FC as in FC-ATA where you're basically using cheap hardware?
> I question your decision to put data and log files on such equipment in
> the first place. However, as to the log files themselves, I suspect you
> could put log files on an MFM drive, or an old 20MB removable platter and
> be fine 99.99% of the time. There just isn't that much I/O to the logs.
> "SBG" <sbg@.thomasville.org> wrote in message
> news:O1j$TY%23HIHA.4196@.TK2MSFTNGP04.phx.gbl...
>> I'm setting up a new DB and separating the log files to storage separate
>> from the data. The data will be on FC storage. Will the log files
>> perform
>> optimally on FC or ATA?
>> Thanks in advance.
>> SBG
>>
>

Failure Audit on domain controller account

I have SQL 2005 installed in a virtual (ESX) environment with a separate DC. Every minute or so an event shows up in the Application Event Log that says:

Type: Failure Audit

User: dgtest\dc1$

Computer: sql1

Source: MSSQLSERVER

Category: (4)

Event ID: 18456

Description:

Login failed for user 'dgtest\dc1$'. [Client: <ip address>]

Data includes: SQL1 master

Any idea what is causing this and how to fix it?

Thanks,
Mindy

Hi Mindy,

I have the same problem. I am running VS2005, SQL2005 in Win XP SP2. I am trying to install Biztalk Server 2006 and I get this error in the event viewer. Due to this error I cannot configure the Groups in Biztalk Server. Do you have any fix?

Thanks,

Sundar

|||Mindy, does this user exist on your box sql1?|||

Has any one found the solution for this problem

|||

I found the solution. It happens when you are specifying BizTalk Server Administrators and BizTalk Server Operators group as the local group. In this case the configuration qizard will try to find these user groups on the SQL machine. If the SQL machine is different from the BizTalk machine, it wil generate error.

To resolve this, just make these 2 groups as domain user groups and change these groups settings within the configuration wizard of BizTalk to domain groups.

|||

Sorry for the delayed response, I did not receive the thread notifications.

The user is actually the domain controller (dc1), not a regular user.

In my installation, there is no Biztalk, only MOSS.

The configuration of the environment (a test/dev environment) has changed significantly since I first posted, and the issue has gone away. Have other issues now, but they are not important ;-)

Mindy

Failure Audit on domain controller account

I have SQL 2005 installed in a virtual (ESX) environment with a separate DC. Every minute or so an event shows up in the Application Event Log that says:

Type: Failure Audit

User: dgtest\dc1$

Computer: sql1

Source: MSSQLSERVER

Category: (4)

Event ID: 18456

Description:

Login failed for user 'dgtest\dc1$'. [Client: <ip address>]

Data includes: SQL1 master

Any idea what is causing this and how to fix it?

Thanks,
Mindy

Hi Mindy,

I have the same problem. I am running VS2005, SQL2005 in Win XP SP2. I am trying to install Biztalk Server 2006 and I get this error in the event viewer. Due to this error I cannot configure the Groups in Biztalk Server. Do you have any fix?

Thanks,

Sundar

|||Mindy, does this user exist on your box sql1?|||

Has any one found the solution for this problem

|||

I found the solution. It happens when you are specifying BizTalk Server Administrators and BizTalk Server Operators group as the local group. In this case the configuration qizard will try to find these user groups on the SQL machine. If the SQL machine is different from the BizTalk machine, it wil generate error.

To resolve this, just make these 2 groups as domain user groups and change these groups settings within the configuration wizard of BizTalk to domain groups.

|||

Sorry for the delayed response, I did not receive the thread notifications.

The user is actually the domain controller (dc1), not a regular user.

In my installation, there is no Biztalk, only MOSS.

The configuration of the environment (a test/dev environment) has changed significantly since I first posted, and the issue has gone away. Have other issues now, but they are not important ;-)

Mindy

Failure Audit on domain controller account

I have SQL 2005 installed in a virtual (ESX) environment with a separate DC. Every minute or so an event shows up in the Application Event Log that says:

Type: Failure Audit

User: dgtest\dc1$

Computer: sql1

Source: MSSQLSERVER

Category: (4)

Event ID: 18456

Description:

Login failed for user 'dgtest\dc1$'. [Client: <ip address>]

Data includes: SQL1 master

Any idea what is causing this and how to fix it?

Thanks,
Mindy

Hi Mindy,

I have the same problem. I am running VS2005, SQL2005 in Win XP SP2. I am trying to install Biztalk Server 2006 and I get this error in the event viewer. Due to this error I cannot configure the Groups in Biztalk Server. Do you have any fix?

Thanks,

Sundar

|||Mindy, does this user exist on your box sql1?|||

Has any one found the solution for this problem

|||

I found the solution. It happens when you are specifying BizTalk Server Administrators and BizTalk Server Operators group as the local group. In this case the configuration qizard will try to find these user groups on the SQL machine. If the SQL machine is different from the BizTalk machine, it wil generate error.

To resolve this, just make these 2 groups as domain user groups and change these groups settings within the configuration wizard of BizTalk to domain groups.

|||

Sorry for the delayed response, I did not receive the thread notifications.

The user is actually the domain controller (dc1), not a regular user.

In my installation, there is no Biztalk, only MOSS.

The configuration of the environment (a test/dev environment) has changed significantly since I first posted, and the issue has gone away. Have other issues now, but they are not important ;-)

Mindy