Re: Err.Raise in COM+ Component loses Err.Source and Err.Description



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 to
get
the error to propagate back to the client side. If I remove it, the
result
is the same. If I store the error, set cnDBMS=Nothing, execute the
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
errors
when the source/description is gone.


"Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:e4Bx40hXGHA.752@xxxxxxxxxxxxxxxxxxxxxxx
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
cnDBMS
object 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:

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
<primarykeyfieldname
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
some
reason (like a foreign key usage issue), an error is raised and we
trap
it
and report to the user the table where the record is used. This has
worked
for a long time.

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
have
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
in
the
proper range (vbObjectError + 3604 where 3604 is the ADO error
number).

Is there something in Windows 2000 that prevents remote error
information?














.



Relevant Pages

  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • This is going straight to the pool room
    ... or not the client has privilege to do what they're trying to do, ... The server environment is this: ... 3GL User action Routines that Tier3 will execute on your behalf during the ... Routine Name: USER_INIT ...
    (comp.os.vms)
  • [Full-Disclosure] R: Full-Disclosure Digest, Vol 3, Issue 42
    ... Full-Disclosure Digest, Vol 3, Issue 42 ... SD Server 4.0.70 Directory Traversal Bug ... Arkeia Network Backup Client Remote Access ...
    (Full-Disclosure)
  • Re: What doesnt lend itself to OO?
    ... > rather than client code. ... no way to do that without also touching the object with clock semantics ... will not encapsulate both clock semantics and network semantics. ... The server can do whatever it wants ...
    (comp.object)
  • RE: Fax monitor incoming + outgoing calls?
    ... problem between the client computer and the SBS server. ... Client is using the internal IP address of the SBS server as the ... To the folder redirection GPO issue: ...
    (microsoft.public.windows.server.sbs)