Anyone have sp_oacreate and SQL2005 issues?

We use a few in house built COM objects that we call from stored procedures
quite often during the day. They are called from linked servers - so all
COM stuff is run on a dedicated box. Both servers are running SQL 2005 SP2.
The server that does all the COM object (sp_oacreate) work will lockup on a
daily basis and we have to restart sql service to fix. Also, we see SPIDs
on the COM box stuck in Rollback status and have to restart SQL to fix. Has
anyone seen any of these issues while migrating to SQL 2005?
Thanks,
Chuck Lathrope
www.sqlwebpedia.com
Chuck,
This is what you mean: - http://support.microsoft.com/kb/937277/en-us
which talks about sp_OAMethod not sp_OACreate.
Chris
"Chuck Lathrope" <computerguy_chuck@.fixmehotmail.com> wrote in message
news:120gcwua7do0w$.106toy5xoolnq.dlg@.40tude.net.. .
> We use a few in house built COM objects that we call from stored
> procedures
> quite often during the day. They are called from linked servers - so all
> COM stuff is run on a dedicated box. Both servers are running SQL 2005
> SP2.
> The server that does all the COM object (sp_oacreate) work will lockup on
> a
> daily basis and we have to restart sql service to fix. Also, we see SPIDs
> on the COM box stuck in Rollback status and have to restart SQL to fix.
> Has
> anyone seen any of these issues while migrating to SQL 2005?
> Thanks,
> Chuck Lathrope
> www.sqlwebpedia.com
|||On Thu, 19 Jul 2007 13:02:00 -0600, Chris Wood wrote:

> http://support.microsoft.com/kb/937277/en-us
That looks very promising! I have been searching net on sp_oacreate and
never saw this. Thanks. I will ask my PSS engineer if I can get the hotfix.
-Chuck
|||Hi Chuck,
Since you are on SP2, i doubt this hotfix will help you, as the SP2
build is 3042, and the above issue is fixed in 2232
HTH,
Dinesh
sql

Anyone have sp_oacreate and SQL2005 issues?

We use a few in house built COM objects that we call from stored procedures
quite often during the day. They are called from linked servers - so all
COM stuff is run on a dedicated box. Both servers are running SQL 2005 SP2.
The server that does all the COM object (sp_oacreate) work will lockup on a
daily basis and we have to restart sql service to fix. Also, we see SPIDs
on the COM box stuck in Rollback status and have to restart SQL to fix. Has
anyone seen any of these issues while migrating to SQL 2005?
Thanks,
Chuck Lathrope
www.sqlwebpedia.comChuck,
This is what you mean: - http://support.microsoft.com/kb/937277/en-us
which talks about sp_OAMethod not sp_OACreate.
Chris
"Chuck Lathrope" <computerguy_chuck@.fixmehotmail.com> wrote in message
news:120gcwua7do0w$.106toy5xoolnq.dlg@.40tude.net...
> We use a few in house built COM objects that we call from stored
> procedures
> quite often during the day. They are called from linked servers - so all
> COM stuff is run on a dedicated box. Both servers are running SQL 2005
> SP2.
> The server that does all the COM object (sp_oacreate) work will lockup on
> a
> daily basis and we have to restart sql service to fix. Also, we see SPIDs
> on the COM box stuck in Rollback status and have to restart SQL to fix.
> Has
> anyone seen any of these issues while migrating to SQL 2005?
> Thanks,
> Chuck Lathrope
> www.sqlwebpedia.com|||On Thu, 19 Jul 2007 13:02:00 -0600, Chris Wood wrote:

> http://support.microsoft.com/kb/937277/en-us
That looks very promising! I have been searching net on sp_oacreate and
never saw this. Thanks. I will ask my PSS engineer if I can get the hotfix.
-Chuck|||Hi Chuck,
Since you are on SP2, i doubt this hotfix will help you, as the SP2
build is 3042, and the above issue is fixed in 2232
HTH,
Dinesh

Anyone have sp_oacreate and SQL2005 issues?

We use a few in house built COM objects that we call from stored procedures
quite often during the day. They are called from linked servers - so all
COM stuff is run on a dedicated box. Both servers are running SQL 2005 SP2.
The server that does all the COM object (sp_oacreate) work will lockup on a
daily basis and we have to restart sql service to fix. Also, we see SPIDs
on the COM box stuck in Rollback status and have to restart SQL to fix. Has
anyone seen any of these issues while migrating to SQL 2005?
Thanks,
Chuck Lathrope
www.sqlwebpedia.comChuck,
This is what you mean: - http://support.microsoft.com/kb/937277/en-us
which talks about sp_OAMethod not sp_OACreate.
Chris
"Chuck Lathrope" <computerguy_chuck@.fixmehotmail.com> wrote in message
news:120gcwua7do0w$.106toy5xoolnq.dlg@.40tude.net...
> We use a few in house built COM objects that we call from stored
> procedures
> quite often during the day. They are called from linked servers - so all
> COM stuff is run on a dedicated box. Both servers are running SQL 2005
> SP2.
> The server that does all the COM object (sp_oacreate) work will lockup on
> a
> daily basis and we have to restart sql service to fix. Also, we see SPIDs
> on the COM box stuck in Rollback status and have to restart SQL to fix.
> Has
> anyone seen any of these issues while migrating to SQL 2005?
> Thanks,
> Chuck Lathrope
> www.sqlwebpedia.com|||On Thu, 19 Jul 2007 13:02:00 -0600, Chris Wood wrote:
> http://support.microsoft.com/kb/937277/en-us
That looks very promising! I have been searching net on sp_oacreate and
never saw this. Thanks. I will ask my PSS engineer if I can get the hotfix.
-Chuck|||Hi Chuck,
Since you are on SP2, i doubt this hotfix will help you, as the SP2
build is 3042, and the above issue is fixed in 2232
HTH,
Dinesh

any ideas?

I have a system currently runs in house only.
The system is for enforcement officers where they are creating and working
on case files.
When they create a new case, the insert statement has logic that will go out
and find the last case number used and then increment that number by 1 and
assign this number as the case number.
I am looking to extend this application to Tablet PC's so they can take the
application out into the field. I have the database setup for merge
replication and I am using the Windows Syncrozination Manager to syncronize
the database when they logged into the network.
I would like to have the ability for them to create a new case while in the
field and disconnected from the network.
that is where the problem comes in, while they are disconnected they won't
know what the last case number was, so I need to assign a temporary case
number till they syncronize, during the syncrozination process assign
permannet case numbers.
Anybody had a situation like this or have any ideas how I could do this?
ThanksHi Mike
I have not deal with you situation, but I could envisage that a solution may
be to sync with a set of "holding" tables rather than the main ones and then
a batch process would update from the main tables at some other point.
John
"Mike Read" wrote:
> I have a system currently runs in house only.
> The system is for enforcement officers where they are creating and working
> on case files.
> When they create a new case, the insert statement has logic that will go out
> and find the last case number used and then increment that number by 1 and
> assign this number as the case number.
> I am looking to extend this application to Tablet PC's so they can take the
> application out into the field. I have the database setup for merge
> replication and I am using the Windows Syncrozination Manager to syncronize
> the database when they logged into the network.
> I would like to have the ability for them to create a new case while in the
> field and disconnected from the network.
> that is where the problem comes in, while they are disconnected they won't
> know what the last case number was, so I need to assign a temporary case
> number till they syncronize, during the syncrozination process assign
> permannet case numbers.
> Anybody had a situation like this or have any ideas how I could do this?
> Thanks
>
>

any ideas?

I have a system currently runs in house only.
The system is for enforcement officers where they are creating and working
on case files.
When they create a new case, the insert statement has logic that will go out
and find the last case number used and then increment that number by 1 and
assign this number as the case number.
I am looking to extend this application to Tablet PC's so they can take the
application out into the field. I have the database setup for merge
replication and I am using the Windows Syncrozination Manager to syncronize
the database when they logged into the network.
I would like to have the ability for them to create a new case while in the
field and disconnected from the network.
that is where the problem comes in, while they are disconnected they won't
know what the last case number was, so I need to assign a temporary case
number till they syncronize, during the syncrozination process assign
permannet case numbers.
Anybody had a situation like this or have any ideas how I could do this?
Thanks
Hi Mike
I have not deal with you situation, but I could envisage that a solution may
be to sync with a set of "holding" tables rather than the main ones and then
a batch process would update from the main tables at some other point.
John
"Mike Read" wrote:

> I have a system currently runs in house only.
> The system is for enforcement officers where they are creating and working
> on case files.
> When they create a new case, the insert statement has logic that will go out
> and find the last case number used and then increment that number by 1 and
> assign this number as the case number.
> I am looking to extend this application to Tablet PC's so they can take the
> application out into the field. I have the database setup for merge
> replication and I am using the Windows Syncrozination Manager to syncronize
> the database when they logged into the network.
> I would like to have the ability for them to create a new case while in the
> field and disconnected from the network.
> that is where the problem comes in, while they are disconnected they won't
> know what the last case number was, so I need to assign a temporary case
> number till they syncronize, during the syncrozination process assign
> permannet case numbers.
> Anybody had a situation like this or have any ideas how I could do this?
> Thanks
>
>

any ideas?

I have a system currently runs in house only.
The system is for enforcement officers where they are creating and working
on case files.
When they create a new case, the insert statement has logic that will go out
and find the last case number used and then increment that number by 1 and
assign this number as the case number.
I am looking to extend this application to Tablet PC's so they can take the
application out into the field. I have the database setup for merge
replication and I am using the Windows Syncrozination Manager to syncronize
the database when they logged into the network.
I would like to have the ability for them to create a new case while in the
field and disconnected from the network.
that is where the problem comes in, while they are disconnected they won't
know what the last case number was, so I need to assign a temporary case
number till they syncronize, during the syncrozination process assign
permannet case numbers.
Anybody had a situation like this or have any ideas how I could do this?
ThanksHi Mike
I have not deal with you situation, but I could envisage that a solution may
be to sync with a set of "holding" tables rather than the main ones and then
a batch process would update from the main tables at some other point.
John
"Mike Read" wrote:

> I have a system currently runs in house only.
> The system is for enforcement officers where they are creating and working
> on case files.
> When they create a new case, the insert statement has logic that will go o
ut
> and find the last case number used and then increment that number by 1 and
> assign this number as the case number.
> I am looking to extend this application to Tablet PC's so they can take th
e
> application out into the field. I have the database setup for merge
> replication and I am using the Windows Syncrozination Manager to syncroniz
e
> the database when they logged into the network.
> I would like to have the ability for them to create a new case while in th
e
> field and disconnected from the network.
> that is where the problem comes in, while they are disconnected they won't
> know what the last case number was, so I need to assign a temporary case
> number till they syncronize, during the syncrozination process assign
> permannet case numbers.
> Anybody had a situation like this or have any ideas how I could do this?
> Thanks
>
>