Re: Err.Raise in COM+ Component loses Err.Source and Err.Description
- From: "Rich M" <rmabry-nospam@xxxxxxxxxxxx>
- Date: Wed, 12 Apr 2006 15:27:38 -0700
More info of note. The "problem" client gets the same generic "Automation
error" on 2 different server machines running the same server-side package.
So, it's definitely something on the client-side preventing the error
details. I wish I had another Win2000 machine I could try as a client to
see if it's specific to Win2000.... I'll look around.
"Rich M" <rmabry-nospam@xxxxxxxxxxxx> wrote in message
news:%230vnlpnXGHA.3684@xxxxxxxxxxxxxxxxxxxxxxx
Sorry - I was trying to simplify the sample code for the sake of the post
and neglected to show the On Error statement. It is most definitely
there.
Like I said, we have one machine here acting as the application server and
SQL server and I can access this code from various WinXP Pro boxes, a
Win2003 Server box via Terminal Server and a Win2000 Pro box, all running
the same build of the client-side package and on the WinXP Pro boxes and
the Win2003 Server machine I get the full Error details. On the Win2000
box I simply get "Automation error".
Here's a crude diagram
( CLIENT : EXE <--> UI-side DLL ) <--{LAN}--> ( SERVER : COM+ DLL <-->
SQL Server)
Using the same SERVER machine and varying CLIENT machines running the same
verison of the EXE and UI-side DLL, I get the differing Error behaviors
described.
"Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:%23nVp2MmXGHA.3328@xxxxxxxxxxxxxxxxxxxxxxx
I had another read of your original post Rich since once you've captured
the
error details they cannot just "disappear". I noticed that there's no 'On
Error' statement directing control to your MTSError label. Hence, if
you're
seeing errors raised from blank/zero details then it's not from the
Err.Raise call in your Delete method. You need to look elsewhere.
Assuming you can reproduce this in the IDE, right-click on a source
window
and select Toggle->Break On All Errors. Then wait for the error to be
trapped
Tony Proctor
"Rich M" <rmabry-nospam@xxxxxxxxxxxx> wrote in message
news:O5BEeXlXGHA.3704@xxxxxxxxxxxxxxxxxxxxxxx
The "Set cnDBMS = Nothing" line is actually something I added trying toget
the error to propagate back to the client side. If I remove it, theresult
is the same. If I store the error, set cnDBMS=Nothing, execute theerrors
SetAbort, and then re-raise the error as your suggestion shows, the
result
is also the same.
This is really frustrating and making it especially hard to diagnose
when the source/description is gone.message
"Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
news:e4Bx40hXGHA.752@xxxxxxxxxxxxxxxxxxxxxxxcnDBMS
Try moving your code that captures the Err details to before the 'Set
cnDBMS
= Nothing' Rich. e.g.
MTSError:
Dim lNum As Long, sSrc As String, sDescr As String
lNum = Err.Number: sSrc = Err.Source: sDescr = Err.Description
Set cnDBMS = Nothing
GetObjectContext.SetAbort
Err.Raise lNum, sSrc, sDescr
End Sub
It may be code that's being executed during the destruction of the
someobject that's affecting the global Err object
Tony Proctor
"Rich M" <rmabry-nospam@xxxxxxxxxxxx> wrote in message
news:#wPMetaXGHA.508@xxxxxxxxxxxxxxxxxxxxxxx
In a COM+ comopnent, we have code which does the following:<primarykeyfieldname
Public Sub Delete(ByVal PrimaryKey as Long, ByVal ConnectionString as
String)
Dim cnDBMS As Connection
Set cnDBMS = New Connection
cnDBMS.Open ConnectionString
cnDBMS.Execute "DELETE FROM <tablename here> WHERE
here> = " & PrimaryKey
GetObjectContext.SetComplete
Set cnDBMS = Nothing
Exit Sub
MTSError:
Set cnDBMS = Nothing
GetObjectContext.SetAbort
Err.Raise Err.Number, Err.Source, Err.Description
End Sub
On the client side, we create an object which creates a remote
instance
of
the COM+ class and calls the Delete method. If the Delete fails for
inreason (like a foreign key usage issue), an error is raised and weworked
trap
it
and report to the user the table where the record is used. This has
for a long time.have
Now, though, we have issues with the COM+ components on a Windows
2003
Server and *some* clients. On our own network, we have a Windows
2003
Server client that we use via Terminal Services and it works fine.
We
many Windows XP Professional clients and they work fine. There is,however,
one Windows 2000 Professional client that, no matter what I've tried,
gets
the Err.Number in the client-side DLL, but the Err.Source is blank
and
Err.Description is simply "Automation Error".
I've tried storing the Err info before the SetAbort and re-raising it
afteward - didn't work.
I've tried changing the Err.Number to something else even though it's
the
proper range (vbObjectError + 3604 where 3604 is the ADO error
number).
Is there something in Windows 2000 that prevents remote error
information?
.
- References:
- Err.Raise in COM+ Component loses Err.Source and Err.Description
- From: Rich M
- Re: Err.Raise in COM+ Component loses Err.Source and Err.Description
- From: Tony Proctor
- Re: Err.Raise in COM+ Component loses Err.Source and Err.Description
- From: Rich M
- Re: Err.Raise in COM+ Component loses Err.Source and Err.Description
- From: Tony Proctor
- Re: Err.Raise in COM+ Component loses Err.Source and Err.Description
- From: Rich M
- Err.Raise in COM+ Component loses Err.Source and Err.Description
- Prev by Date: Re: BorderStyle doesn't change at RunTime
- Next by Date: Re: Mplayer: click event has a conflict with DblClick
- Previous by thread: Re: Err.Raise in COM+ Component loses Err.Source and Err.Description
- Next by thread: Function
- Index(es):
Relevant Pages
|
|