Re: Remote debugging outside of domain
I'm guessing windbg gives you the same problems? In some respects it's better than remotedebugger and VisualStudio On 9 August 2010 13:35, Michael Lyons wrote: > Yes I have tried that and unfortunately it’s only native which means I > lose the ability to set break points as it doesn’t recognise the PDB’s. > > > > - > Michael Lyons > > > > *From:* ozdotnet-boun...@ozdotnet.com [mailto: > ozdotnet-boun...@ozdotnet.com] *On Behalf Of *mike smith > *Sent:* Monday, 9 August 2010 1:26 PM > *To:* ozDotNet > *Subject:* Re: Remote debugging outside of domain > > > > It's probably bad security, (but if you're inside a LAN or connecting via > VPN or SSH it likely doesn't matter) but have you tried going to the options > dialog (inside remote debugger stub) and tick allow any user to debug? > > On 8 August 2010 20:02, Michael Lyons wrote: > > I'm needing to debug a Windows service to see why it is crashing after a > few > minutes. > I've setup the remote debugger on the host machine, but I receive the error > message "Unable to connect to the Microsoft Visual Studio Remote Debugging > Monitor named 'x'. Logon Failure: unknown username or bad password". > The issue is that my workstation is within a AD domain whilst the machine I > wish to debug is not. How can I go about debugging the remote machine > without disconnecting from the domain or connecting the remote machine to > the domain? > > The service has also for some reason or another stopped outputting to via > System.Diagnostics.EventLogTraceListener, would anyone have any clue why > this would happen? > > - > Michael Lyons > > > > > -- > Meski > > "Going to Starbucks for coffee is like going to prison for sex. Sure, > you'll get it, but it's going to be rough" - Adam Hills > -- Meski "Going to Starbucks for coffee is like going to prison for sex. Sure, you'll get it, but it's going to be rough" - Adam Hills
Re: I don't like Linq to Entities
Single() shouldn't have to find all results, it just has to check if there is more than one. On Mon, Aug 9, 2010 at 2:49 PM, Michael Minutillo wrote: > First should be quicker than Single shouldn't it? First just has to find one > result. Single has to find all results and ensure there is only one. > > > Michael M. Minutillo > Indiscriminate Information Sponge > Blog: http://wolfbyte-net.blogspot.com > > > On Mon, Aug 9, 2010 at 12:10 PM, wrote: >> >> Yea but you could always use First, right? Single would only be >> fractionally faster, if at all, >> methinks.. >> >> >> On Mon, Aug 9th, 2010 at 1:30 PM, Michael Lyons >> wrote: >> >> > I totally agree with you Tony. I've always felt the LINQ to SQL designer >> > was >> > somewhat more thought out and aimed at the whole KISS principle, while >> > LINQ >> > to Entities tried to be "enterprisey" when it really didn't need to be. >> > >> > Admittedly I haven't taken a look at EF since back when it first came >> > out, >> > with my biggest turn off being Single() / SingleOrDefault() missing. Has >> > this been added now? >> > >> > - >> > Michael Lyons >> > >> > >> > -Original Message- >> > From: ozdotnet-boun...@ozdotnet.com >> > [mailto:ozdotnet-boun...@ozdotnet.com] >> > On Behalf Of ton...@tpg.com.au >> > Sent: Monday, 9 August 2010 12:19 PM >> > To: ozdotnet@ozdotnet.com >> > Subject: I don't like Linq to Entities >> > >> > Hi all, >> > >> > I have my archidev hat on at the moment (given my last few emails I'm >> > betting that doesn't >> > surprise people) >> > >> > One task I have been looking at is figuring out how to convert our >> > applications from Linq to SQL >> > over to Linq to Entities. The reasons are that Linq to Entities is >> > installed >> > out-of-the-box, and Linq to >> > SQL has to be added in (this implies a preference by Microsoft), LINQ to >> > SQL >> > is no longer receiving >> > support from Microsoft, and LINQ to Entities supports multiple databases >> > and >> > devices. >> > >> > Apart from that, it provides much of the same; everything that Linq to >> > SQL >> > does, Linq to Entities >> > can certainly do. But Linq to Entities gives me no other real advantages >> > within my environment >> > other than "architectural correctness" perhaps. >> > >> > But LINQ to SQL has one distinct advantage over Linq to Entities. >> > >> > This is the major major gripe that I have, and on this basis is enough >> > for >> > me to choose SQL over >> > Entities. >> > >> > When I drag a stored procedure from the server explorer onto my linq to >> > sql >> > designer, the stored >> > proc appears in the designer in a column on the right. If I have other >> > objects on the designer, such >> > as a table/entity, I can map the stored proc output to that object. It's >> > all >> > visual and I can see >> > whether everthing has been done right. It's also simple for my >> > developers >> > to >> > see whether they've >> > provided everything they're meant to provide when returning data from >> > the >> > database. >> > >> > In the LINQ to Entities case, I drag a stored proc onto the designer. It >> > _disappears_ into the ether. >> > Yes, it was added, but there's nothing visual on the designer to tell me >> > that. Not only that, but I >> > have to _map_ the stored proc to a function by using a right-click >> > context >> > menu and performing a >> > function import. After the function import, the routine is available to >> > be >> > called, but it still does not >> > appear on the designer. I have to open the Model Browser to find my >> > stored >> > proc, and that's on a >> > tab behind my solution explorer. >> > >> > So that, and that alone, is enough to make me reject LINQ to Entities. >> > It >> > is >> > the pain of extra >> > administration. And it shouldn't be that hard for the designer to be >> > fixed >> > to behave in a similar >> > fashion to LINQ to SQL as well. There is nothing that says that it would >> > be >> > impossible for a stored >> > procedure to be dragged onto the canvas and have the function imported >> > immediately based on >> > the stored procedure name, and have the stored procedure itself >> > available >> > via the properties of >> > that function. >> > >> > So that's my gripe. >> > >> > Regards, >> > Tony >> > >> > >> > >> >> >> > >
Re: I don't like Linq to Entities
First should be quicker than Single shouldn't it? First just has to find one result. Single has to find all results and ensure there is only one. Michael M. Minutillo Indiscriminate Information Sponge Blog: http://wolfbyte-net.blogspot.com On Mon, Aug 9, 2010 at 12:10 PM, wrote: > Yea but you could always use First, right? Single would only be > fractionally faster, if at all, > methinks.. > > > On Mon, Aug 9th, 2010 at 1:30 PM, Michael Lyons > wrote: > > > I totally agree with you Tony. I've always felt the LINQ to SQL designer > > was > > somewhat more thought out and aimed at the whole KISS principle, while > > LINQ > > to Entities tried to be "enterprisey" when it really didn't need to be. > > > > Admittedly I haven't taken a look at EF since back when it first came > > out, > > with my biggest turn off being Single() / SingleOrDefault() missing. Has > > this been added now? > > > > - > > Michael Lyons > > > > > > -Original Message- > > From: ozdotnet-boun...@ozdotnet.com > > [mailto:ozdotnet-boun...@ozdotnet.com] > > On Behalf Of ton...@tpg.com.au > > Sent: Monday, 9 August 2010 12:19 PM > > To: ozdotnet@ozdotnet.com > > Subject: I don't like Linq to Entities > > > > Hi all, > > > > I have my archidev hat on at the moment (given my last few emails I'm > > betting that doesn't > > surprise people) > > > > One task I have been looking at is figuring out how to convert our > > applications from Linq to SQL > > over to Linq to Entities. The reasons are that Linq to Entities is > > installed > > out-of-the-box, and Linq to > > SQL has to be added in (this implies a preference by Microsoft), LINQ to > > SQL > > is no longer receiving > > support from Microsoft, and LINQ to Entities supports multiple databases > > and > > devices. > > > > Apart from that, it provides much of the same; everything that Linq to > > SQL > > does, Linq to Entities > > can certainly do. But Linq to Entities gives me no other real advantages > > within my environment > > other than "architectural correctness" perhaps. > > > > But LINQ to SQL has one distinct advantage over Linq to Entities. > > > > This is the major major gripe that I have, and on this basis is enough > > for > > me to choose SQL over > > Entities. > > > > When I drag a stored procedure from the server explorer onto my linq to > > sql > > designer, the stored > > proc appears in the designer in a column on the right. If I have other > > objects on the designer, such > > as a table/entity, I can map the stored proc output to that object. It's > > all > > visual and I can see > > whether everthing has been done right. It's also simple for my developers > > to > > see whether they've > > provided everything they're meant to provide when returning data from the > > database. > > > > In the LINQ to Entities case, I drag a stored proc onto the designer. It > > _disappears_ into the ether. > > Yes, it was added, but there's nothing visual on the designer to tell me > > that. Not only that, but I > > have to _map_ the stored proc to a function by using a right-click > > context > > menu and performing a > > function import. After the function import, the routine is available to > > be > > called, but it still does not > > appear on the designer. I have to open the Model Browser to find my > > stored > > proc, and that's on a > > tab behind my solution explorer. > > > > So that, and that alone, is enough to make me reject LINQ to Entities. It > > is > > the pain of extra > > administration. And it shouldn't be that hard for the designer to be > > fixed > > to behave in a similar > > fashion to LINQ to SQL as well. There is nothing that says that it would > > be > > impossible for a stored > > procedure to be dragged onto the canvas and have the function imported > > immediately based on > > the stored procedure name, and have the stored procedure itself available > > via the properties of > > that function. > > > > So that's my gripe. > > > > Regards, > > Tony > > > > > > > > > >
RE: Remote debugging outside of domain
Coincidently I spoke to the PM on this feature last week about this very issue. It's a known limitation - which requires a re-architecture of the remote debugging engine. Unfortunately, you won't see this supported until a future version of VS. -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Michael Lyons Sent: Sunday, August 08, 2010 8:19 PM To: 'ozDotNet' Subject: RE: Remote debugging outside of domain I have to say it would be really nice if it just worked similar to what you were saying but popped up with an authentication dialog where you could actually logon remotely using the debugging account. - Michael Lyons -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Wallace Turner Sent: Monday, 9 August 2010 11:52 AM To: 'ozDotNet' Subject: RE: Remote debugging outside of domain Condolences++ Why do you make it so damn hard to debug a process on a remote machine (listen up Microsoft) As always, I'm sure there is a good reason for everything but this is what would be nice: a) you install remote debugging on remote machine b) you forward port on firewall (optionally) c) enter remote machine name a la SQL connections (myhost.com,5000) and start debugging Yes I know it doesn't work this way. Geez it would be nice tho. No messing around with users, one port only. Security could be controlled per process via the remote debugging frontend on the remote machine (yes that would require some work) -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Monday, 9 August 2010 11:47 AM To: 'ozDotNet' Subject: RE: Remote debugging outside of domain "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor names 'x'. The Visual Studio Remote Debugger on the target computer cannot connect back to this computer. Authentication failed. Please see Help for assistance." Hi Michael, my condolences. I spent many solid hours of suffering one afternoon last year trying every trick I could think of to get around this exact problem ... I failed. I gave up with remote debugging and used windbg on the server machine to attach to the troublesome process and I eventually found the problem (missing resource files). Sorry I can't offer any more than sympathy. Greg
RE: I don't like Linq to Entities
Yea but you could always use First, right? Single would only be fractionally faster, if at all, methinks.. On Mon, Aug 9th, 2010 at 1:30 PM, Michael Lyons wrote: > I totally agree with you Tony. I've always felt the LINQ to SQL designer > was > somewhat more thought out and aimed at the whole KISS principle, while > LINQ > to Entities tried to be "enterprisey" when it really didn't need to be. > > Admittedly I haven't taken a look at EF since back when it first came > out, > with my biggest turn off being Single() / SingleOrDefault() missing. Has > this been added now? > > - > Michael Lyons > > > -Original Message- > From: ozdotnet-boun...@ozdotnet.com > [mailto:ozdotnet-boun...@ozdotnet.com] > On Behalf Of ton...@tpg.com.au > Sent: Monday, 9 August 2010 12:19 PM > To: ozdotnet@ozdotnet.com > Subject: I don't like Linq to Entities > > Hi all, > > I have my archidev hat on at the moment (given my last few emails I'm > betting that doesn't > surprise people) > > One task I have been looking at is figuring out how to convert our > applications from Linq to SQL > over to Linq to Entities. The reasons are that Linq to Entities is > installed > out-of-the-box, and Linq to > SQL has to be added in (this implies a preference by Microsoft), LINQ to > SQL > is no longer receiving > support from Microsoft, and LINQ to Entities supports multiple databases > and > devices. > > Apart from that, it provides much of the same; everything that Linq to > SQL > does, Linq to Entities > can certainly do. But Linq to Entities gives me no other real advantages > within my environment > other than "architectural correctness" perhaps. > > But LINQ to SQL has one distinct advantage over Linq to Entities. > > This is the major major gripe that I have, and on this basis is enough > for > me to choose SQL over > Entities. > > When I drag a stored procedure from the server explorer onto my linq to > sql > designer, the stored > proc appears in the designer in a column on the right. If I have other > objects on the designer, such > as a table/entity, I can map the stored proc output to that object. It's > all > visual and I can see > whether everthing has been done right. It's also simple for my developers > to > see whether they've > provided everything they're meant to provide when returning data from the > database. > > In the LINQ to Entities case, I drag a stored proc onto the designer. It > _disappears_ into the ether. > Yes, it was added, but there's nothing visual on the designer to tell me > that. Not only that, but I > have to _map_ the stored proc to a function by using a right-click > context > menu and performing a > function import. After the function import, the routine is available to > be > called, but it still does not > appear on the designer. I have to open the Model Browser to find my > stored > proc, and that's on a > tab behind my solution explorer. > > So that, and that alone, is enough to make me reject LINQ to Entities. It > is > the pain of extra > administration. And it shouldn't be that hard for the designer to be > fixed > to behave in a similar > fashion to LINQ to SQL as well. There is nothing that says that it would > be > impossible for a stored > procedure to be dragged onto the canvas and have the function imported > immediately based on > the stored procedure name, and have the stored procedure itself available > via the properties of > that function. > > So that's my gripe. > > Regards, > Tony > > >
RE: Remote debugging outside of domain
Yes I have tried that and unfortunately it’s only native which means I lose the ability to set break points as it doesn’t recognise the PDB’s. - Michael Lyons From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of mike smith Sent: Monday, 9 August 2010 1:26 PM To: ozDotNet Subject: Re: Remote debugging outside of domain It's probably bad security, (but if you're inside a LAN or connecting via VPN or SSH it likely doesn't matter) but have you tried going to the options dialog (inside remote debugger stub) and tick allow any user to debug? On 8 August 2010 20:02, Michael Lyons wrote: I'm needing to debug a Windows service to see why it is crashing after a few minutes. I've setup the remote debugger on the host machine, but I receive the error message "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'x'. Logon Failure: unknown username or bad password". The issue is that my workstation is within a AD domain whilst the machine I wish to debug is not. How can I go about debugging the remote machine without disconnecting from the domain or connecting the remote machine to the domain? The service has also for some reason or another stopped outputting to via System.Diagnostics.EventLogTraceListener, would anyone have any clue why this would happen? - Michael Lyons -- Meski "Going to Starbucks for coffee is like going to prison for sex. Sure, you'll get it, but it's going to be rough" - Adam Hills
RE: I don't like Linq to Entities
I totally agree with you Tony. I've always felt the LINQ to SQL designer was somewhat more thought out and aimed at the whole KISS principle, while LINQ to Entities tried to be "enterprisey" when it really didn't need to be. Admittedly I haven't taken a look at EF since back when it first came out, with my biggest turn off being Single() / SingleOrDefault() missing. Has this been added now? - Michael Lyons -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of ton...@tpg.com.au Sent: Monday, 9 August 2010 12:19 PM To: ozdotnet@ozdotnet.com Subject: I don't like Linq to Entities Hi all, I have my archidev hat on at the moment (given my last few emails I'm betting that doesn't surprise people) One task I have been looking at is figuring out how to convert our applications from Linq to SQL over to Linq to Entities. The reasons are that Linq to Entities is installed out-of-the-box, and Linq to SQL has to be added in (this implies a preference by Microsoft), LINQ to SQL is no longer receiving support from Microsoft, and LINQ to Entities supports multiple databases and devices. Apart from that, it provides much of the same; everything that Linq to SQL does, Linq to Entities can certainly do. But Linq to Entities gives me no other real advantages within my environment other than "architectural correctness" perhaps. But LINQ to SQL has one distinct advantage over Linq to Entities. This is the major major gripe that I have, and on this basis is enough for me to choose SQL over Entities. When I drag a stored procedure from the server explorer onto my linq to sql designer, the stored proc appears in the designer in a column on the right. If I have other objects on the designer, such as a table/entity, I can map the stored proc output to that object. It's all visual and I can see whether everthing has been done right. It's also simple for my developers to see whether they've provided everything they're meant to provide when returning data from the database. In the LINQ to Entities case, I drag a stored proc onto the designer. It _disappears_ into the ether. Yes, it was added, but there's nothing visual on the designer to tell me that. Not only that, but I have to _map_ the stored proc to a function by using a right-click context menu and performing a function import. After the function import, the routine is available to be called, but it still does not appear on the designer. I have to open the Model Browser to find my stored proc, and that's on a tab behind my solution explorer. So that, and that alone, is enough to make me reject LINQ to Entities. It is the pain of extra administration. And it shouldn't be that hard for the designer to be fixed to behave in a similar fashion to LINQ to SQL as well. There is nothing that says that it would be impossible for a stored procedure to be dragged onto the canvas and have the function imported immediately based on the stored procedure name, and have the stored procedure itself available via the properties of that function. So that's my gripe. Regards, Tony
Re: Remote debugging outside of domain
It's probably bad security, (but if you're inside a LAN or connecting via VPN or SSH it likely doesn't matter) but have you tried going to the options dialog (inside remote debugger stub) and tick allow any user to debug? On 8 August 2010 20:02, Michael Lyons wrote: > I'm needing to debug a Windows service to see why it is crashing after a > few > minutes. > I've setup the remote debugger on the host machine, but I receive the error > message "Unable to connect to the Microsoft Visual Studio Remote Debugging > Monitor named 'x'. Logon Failure: unknown username or bad password". > The issue is that my workstation is within a AD domain whilst the machine I > wish to debug is not. How can I go about debugging the remote machine > without disconnecting from the domain or connecting the remote machine to > the domain? > > The service has also for some reason or another stopped outputting to via > System.Diagnostics.EventLogTraceListener, would anyone have any clue why > this would happen? > > - > Michael Lyons > > -- Meski "Going to Starbucks for coffee is like going to prison for sex. Sure, you'll get it, but it's going to be rough" - Adam Hills
RE: Remote debugging outside of domain
I have to say it would be really nice if it just worked similar to what you were saying but popped up with an authentication dialog where you could actually logon remotely using the debugging account. - Michael Lyons -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Wallace Turner Sent: Monday, 9 August 2010 11:52 AM To: 'ozDotNet' Subject: RE: Remote debugging outside of domain Condolences++ Why do you make it so damn hard to debug a process on a remote machine (listen up Microsoft) As always, I'm sure there is a good reason for everything but this is what would be nice: a) you install remote debugging on remote machine b) you forward port on firewall (optionally) c) enter remote machine name a la SQL connections (myhost.com,5000) and start debugging Yes I know it doesn't work this way. Geez it would be nice tho. No messing around with users, one port only. Security could be controlled per process via the remote debugging frontend on the remote machine (yes that would require some work) -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Monday, 9 August 2010 11:47 AM To: 'ozDotNet' Subject: RE: Remote debugging outside of domain "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor names 'x'. The Visual Studio Remote Debugger on the target computer cannot connect back to this computer. Authentication failed. Please see Help for assistance." Hi Michael, my condolences. I spent many solid hours of suffering one afternoon last year trying every trick I could think of to get around this exact problem ... I failed. I gave up with remote debugging and used windbg on the server machine to attach to the troublesome process and I eventually found the problem (missing resource files). Sorry I can't offer any more than sympathy. Greg
RE: Remote debugging outside of domain
I previously had it working once before on another project, but that was before we put our workstations into a domain and it was a slight challenge for 30 minutes, but then all ran smoothly. The notebook idea isn't a bad idea, but it's not really an ideal long term solution. Would be nice if there was a way to just tell Windows to dump all method calls with arguments and exceptions to the hard disk without having to do too much overhead such as tracing. I'm sure it could be done as it's similar to what most profilers do. Maybe I could possibly run a profiler thought it and find the answer with some guess work. - Michael Lyons -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Maddin, Peter Sent: Monday, 9 August 2010 11:25 AM To: ozDotNet Subject: RE: Remote debugging outside of domain If I was in this position, I would install VS on a notebook (if you don't have one spare, they are pretty cheap these days) and place it in the same network environment as your server. I would then use remote debugging to discover the issue and if necessary nuke the notebook afterwards. >From all the pain you are going through, maybe a simple approach would be quicker. That being said I have only debugged services remotely within a domain (and I found that challenging enough). Regards Peter Maddin Applications Development Officer PathWest Laboratory Medicine WA Phone : +618 9473 3944 Fax : +618 9473 3982 E-Mail : peter.mad...@pathwest.wa.gov.au The contents of this e-mail transmission outside of the WAGHS network are intended solely for the named recipient's), may be confidential, and may be privileged or otherwise protected from disclosure in the public interest. The use, reproduction, disclosure or distribution of the contents of this e-mail transmission by any person other than the named recipient(s) is prohibited. If you are not a named recipient please notify the sender immediately.
I don't like Linq to Entities
Hi all, I have my archidev hat on at the moment (given my last few emails I'm betting that doesn't surprise people) One task I have been looking at is figuring out how to convert our applications from Linq to SQL over to Linq to Entities. The reasons are that Linq to Entities is installed out-of-the-box, and Linq to SQL has to be added in (this implies a preference by Microsoft), LINQ to SQL is no longer receiving support from Microsoft, and LINQ to Entities supports multiple databases and devices. Apart from that, it provides much of the same; everything that Linq to SQL does, Linq to Entities can certainly do. But Linq to Entities gives me no other real advantages within my environment other than "architectural correctness" perhaps. But LINQ to SQL has one distinct advantage over Linq to Entities. This is the major major gripe that I have, and on this basis is enough for me to choose SQL over Entities. When I drag a stored procedure from the server explorer onto my linq to sql designer, the stored proc appears in the designer in a column on the right. If I have other objects on the designer, such as a table/entity, I can map the stored proc output to that object. It's all visual and I can see whether everthing has been done right. It's also simple for my developers to see whether they've provided everything they're meant to provide when returning data from the database. In the LINQ to Entities case, I drag a stored proc onto the designer. It _disappears_ into the ether. Yes, it was added, but there's nothing visual on the designer to tell me that. Not only that, but I have to _map_ the stored proc to a function by using a right-click context menu and performing a function import. After the function import, the routine is available to be called, but it still does not appear on the designer. I have to open the Model Browser to find my stored proc, and that's on a tab behind my solution explorer. So that, and that alone, is enough to make me reject LINQ to Entities. It is the pain of extra administration. And it shouldn't be that hard for the designer to be fixed to behave in a similar fashion to LINQ to SQL as well. There is nothing that says that it would be impossible for a stored procedure to be dragged onto the canvas and have the function imported immediately based on the stored procedure name, and have the stored procedure itself available via the properties of that function. So that's my gripe. Regards, Tony
RE: Remote debugging outside of domain
Condolences++ Why do you make it so damn hard to debug a process on a remote machine (listen up Microsoft) As always, I'm sure there is a good reason for everything but this is what would be nice: a) you install remote debugging on remote machine b) you forward port on firewall (optionally) c) enter remote machine name a la SQL connections (myhost.com,5000) and start debugging Yes I know it doesn't work this way. Geez it would be nice tho. No messing around with users, one port only. Security could be controlled per process via the remote debugging frontend on the remote machine (yes that would require some work) -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Monday, 9 August 2010 11:47 AM To: 'ozDotNet' Subject: RE: Remote debugging outside of domain "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor names 'x'. The Visual Studio Remote Debugger on the target computer cannot connect back to this computer. Authentication failed. Please see Help for assistance." Hi Michael, my condolences. I spent many solid hours of suffering one afternoon last year trying every trick I could think of to get around this exact problem ... I failed. I gave up with remote debugging and used windbg on the server machine to attach to the troublesome process and I eventually found the problem (missing resource files). Sorry I can't offer any more than sympathy. Greg
RE: Remote debugging outside of domain
"Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor names 'x'. The Visual Studio Remote Debugger on the target computer cannot connect back to this computer. Authentication failed. Please see Help for assistance." Hi Michael, my condolences. I spent many solid hours of suffering one afternoon last year trying every trick I could think of to get around this exact problem ... I failed. I gave up with remote debugging and used windbg on the server machine to attach to the troublesome process and I eventually found the problem (missing resource files). Sorry I can't offer any more than sympathy. Greg
SQL Server SCOPE_IDENTITY() has a bug
Hi all, According to: https://connect.microsoft.com/SQLServer/feedback/details/328811/scope-identity-sometimes- returns-incorrect-value SCOPE_IDENTITY() has a bug that causes it to fail whenever parallelism kicks in (a more common occurence these days with the proliferation of multiprocessor machines). Microsoft has been unable to solve the problem, and the bug is still open on Connect. One of the workaround specified is the following: 2. Read the value from SELECT part into a set of variables (or single table variable) and then insert into the target table with MAX_DOP=1. Since the INSERT plan will not be parallel you will get the right semantic, yet your SELECT will be parallel to achieve performance there if you really need it. But as far as I can figure out, this workaround should not need the MAX_DOP=1 option, because when inserting from values, there won't be a parallel case! My insert statement is always inserting a single row. Is this correct? Regards, Tony
RE: Remote debugging outside of domain
If I was in this position, I would install VS on a notebook (if you don't have one spare, they are pretty cheap these days) and place it in the same network environment as your server. I would then use remote debugging to discover the issue and if necessary nuke the notebook afterwards. >From all the pain you are going through, maybe a simple approach would be >quicker. That being said I have only debugged services remotely within a domain (and I found that challenging enough). Regards Peter Maddin Applications Development Officer PathWest Laboratory Medicine WA Phone : +618 9473 3944 Fax : +618 9473 3982 E-Mail : peter.mad...@pathwest.wa.gov.au The contents of this e-mail transmission outside of the WAGHS network are intended solely for the named recipient's), may be confidential, and may be privileged or otherwise protected from disclosure in the public interest. The use, reproduction, disclosure or distribution of the contents of this e-mail transmission by any person other than the named recipient(s) is prohibited. If you are not a named recipient please notify the sender immediately.
RE: Remote debugging outside of domain
I've turned both off with no firewalls in between. :( - Michael Lyons -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Richards Sent: Monday, 9 August 2010 10:53 AM To: ozDotNet Subject: Re: Remote debugging outside of domain Windows (or any other) firewall maybe? David "If we can hit that bullseye, the rest of the dominoes will fall like a house of cards... checkmate!" -Zapp Brannigan, Futurama On Mon, Aug 9, 2010 at 10:50, Michael Lyons wrote: > S close. I can see that it logged on the remote host with the same > username, but now it's spewing out another error. > > "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor > names 'x'. The Visual Studio Remote Debugger on the target computer cannot > connect back to this computer. Authentication failed. Please see Help for > assistance." > > I checked help and it only talks about making sure that the machines can > actually see each other which they can. I even have put the full > workstations domain address into the windows hosts file just in case it may > be getting confused by the domain but to no avail. > > - > Michael Lyons > >
RE: Remote debugging outside of domain
I've used windbg before with crash dumps and I can even use the 'Problem reports and solutions' section under control panel to kind of see where the error is happening. But under test conditions this seems to work fine. I'm sure it's something to do with specific machine and particular function parameter information which I really need a full blown debugger to figure this one out. I really would prefer to get remote debugger working as this is our staging machine for an external environment which is fine to always debug on - just would prefer not having to install VS on the machine itself and worry about licensing issues. - Michael Lyons -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Wallace Turner Sent: Monday, 9 August 2010 10:18 AM To: 'ozDotNet' Subject: RE: Remote debugging outside of domain If you are still stuck then I would give windbg a try (see earlier post ' Unable to diagnose a crash') as it may be able to give you enough info to fix the problem -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Michael Lyons Sent: Monday, 9 August 2010 9:12 AM To: ozdotnet@ozdotnet.com Subject: RE: Remote debugging outside of domain No luck. Same result. Liked the idea though. I also made sure that the user was in the VS remote debugger permissions and they had debugging permissions under the local security policies. - Michael Lyons -Original Message- From: Ken Schaefer [mailto:k...@adopenstatic.com] Sent: Sunday, 8 August 2010 9:50 PM To: Michael Lyons Subject: RE: Remote debugging outside of domain One option to try: Connect to shared folder on the remote machine first (e.g. c$ admin share) using Explorer Then VS. NET might use your established credentials to attempt to connect to the remote debugger service Cheers Ken -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Michael Lyons Sent: Sunday, 8 August 2010 8:03 PM To: 'ozDotNet' Subject: Remote debugging outside of domain I'm needing to debug a Windows service to see why it is crashing after a few minutes. I've setup the remote debugger on the host machine, but I receive the error message "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'x'. Logon Failure: unknown username or bad password". The issue is that my workstation is within a AD domain whilst the machine I wish to debug is not. How can I go about debugging the remote machine without disconnecting from the domain or connecting the remote machine to the domain? The service has also for some reason or another stopped outputting to via System.Diagnostics.EventLogTraceListener, would anyone have any clue why this would happen? - Michael Lyons
Re: Remote debugging outside of domain
Windows (or any other) firewall maybe? David "If we can hit that bullseye, the rest of the dominoes will fall like a house of cards... checkmate!" -Zapp Brannigan, Futurama On Mon, Aug 9, 2010 at 10:50, Michael Lyons wrote: > S close. I can see that it logged on the remote host with the same > username, but now it's spewing out another error. > > "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor > names 'x'. The Visual Studio Remote Debugger on the target computer cannot > connect back to this computer. Authentication failed. Please see Help for > assistance." > > I checked help and it only talks about making sure that the machines can > actually see each other which they can. I even have put the full > workstations domain address into the windows hosts file just in case it may > be getting confused by the domain but to no avail. > > - > Michael Lyons > >
RE: Remote debugging outside of domain
S close. I can see that it logged on the remote host with the same username, but now it's spewing out another error. "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor names 'x'. The Visual Studio Remote Debugger on the target computer cannot connect back to this computer. Authentication failed. Please see Help for assistance." I checked help and it only talks about making sure that the machines can actually see each other which they can. I even have put the full workstations domain address into the windows hosts file just in case it may be getting confused by the domain but to no avail. - Michael Lyons -Original Message- From: Ken Schaefer [mailto:k...@adopenstatic.com] Sent: Monday, 9 August 2010 9:13 AM To: Michael Lyons Subject: RE: Remote debugging outside of domain Can you create a local user on the remote machine that has the same username/password that you have in the AD domain? Cheers Ken -Original Message- From: Michael Lyons [mailto:maill...@ittworx.com] Sent: Monday, 9 August 2010 9:09 AM To: Ken Schaefer Subject: RE: Remote debugging outside of domain No luck. Same result. Liked the idea though. I also made sure that the user was in the VS remote debugger permissions and they had debugging permissions under the local security policies. - Michael Lyons -Original Message- From: Ken Schaefer [mailto:k...@adopenstatic.com] Sent: Sunday, 8 August 2010 9:50 PM To: Michael Lyons Subject: RE: Remote debugging outside of domain One option to try: Connect to shared folder on the remote machine first (e.g. c$ admin share) using Explorer Then VS. NET might use your established credentials to attempt to connect to the remote debugger service Cheers Ken -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Michael Lyons Sent: Sunday, 8 August 2010 8:03 PM To: 'ozDotNet' Subject: Remote debugging outside of domain I'm needing to debug a Windows service to see why it is crashing after a few minutes. I've setup the remote debugger on the host machine, but I receive the error message "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'x'. Logon Failure: unknown username or bad password". The issue is that my workstation is within a AD domain whilst the machine I wish to debug is not. How can I go about debugging the remote machine without disconnecting from the domain or connecting the remote machine to the domain? The service has also for some reason or another stopped outputting to via System.Diagnostics.EventLogTraceListener, would anyone have any clue why this would happen? - Michael Lyons
RE: Remote debugging outside of domain
If you are still stuck then I would give windbg a try (see earlier post ' Unable to diagnose a crash') as it may be able to give you enough info to fix the problem -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Michael Lyons Sent: Monday, 9 August 2010 9:12 AM To: ozdotnet@ozdotnet.com Subject: RE: Remote debugging outside of domain No luck. Same result. Liked the idea though. I also made sure that the user was in the VS remote debugger permissions and they had debugging permissions under the local security policies. - Michael Lyons -Original Message- From: Ken Schaefer [mailto:k...@adopenstatic.com] Sent: Sunday, 8 August 2010 9:50 PM To: Michael Lyons Subject: RE: Remote debugging outside of domain One option to try: Connect to shared folder on the remote machine first (e.g. c$ admin share) using Explorer Then VS. NET might use your established credentials to attempt to connect to the remote debugger service Cheers Ken -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Michael Lyons Sent: Sunday, 8 August 2010 8:03 PM To: 'ozDotNet' Subject: Remote debugging outside of domain I'm needing to debug a Windows service to see why it is crashing after a few minutes. I've setup the remote debugger on the host machine, but I receive the error message "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'x'. Logon Failure: unknown username or bad password". The issue is that my workstation is within a AD domain whilst the machine I wish to debug is not. How can I go about debugging the remote machine without disconnecting from the domain or connecting the remote machine to the domain? The service has also for some reason or another stopped outputting to via System.Diagnostics.EventLogTraceListener, would anyone have any clue why this would happen? - Michael Lyons
Re: SQL Server Deadlock on Insert
Tony Something I've seen several times: The table doesn't have a trigger to update the row with a datetime stamp on row insert/modify. Simon On 9/08/2010 9:47 AM, ton...@tpg.com.au wrote: Hi all, I am currently trying to improve the template code in our stored proc generator. In the insert stored proc, there seems to be a lot of code with references to deadlock detection, and attempts to re-run the insert if it fails due to a deadlock. But the insert statement itself has a ROWLOCK hint on it. (See example below) So I can't see how it could possibly get a deadlock if the row hasn't previously existed. Although that said, if it was escalated to a table lock in the context of a much larger transaction perhaps it could happen. What do people do with respect to dead lock detection in their stored procs? Regards, Tony ALTER PROCEDURE [Common].[ApplicationParameterInsert] @Id int output, @Name nvarchar(50), @Description nvarchar(255), @Value nvarchar(255), @DataType nvarchar(50), @UserId uniqueIdentifier, @RowVersion rowversion output AS BEGIN -- SET DEFAULT BEHAVIOR SET NOCOUNT ON -- Performance: stops rows affected messages SET DEADLOCK_PRIORITY LOW -- This SP to be the Deadlock victim -- Initialise Lock-Timeout and Deadlock vars for Insert DECLARE @iLockTimeoutRetries as int DECLARE @IdeadLockRetries as int DECLARE @dtLockTimeoutSleepInterval as datetime DECLARE @dtDeadlockSleepInterval as datetime DECLARE @iErrorNumber as int SET @iLockTimeoutRetries = 0 SET @IdeadLockRetries = 0 SET @dtLockTimeoutSleepInterval = Common.fnLockTimeoutSleepInterval() SET @dtDeadlockSleepInterval= Common.fnDeadlockSleepInterval() SET @iErrorNumber = 0 RETRY: BEGIN TRY -- Insert Record Insert Into [Common].[ApplicationParameter] WITH (ROWLOCK) ( [ModifiedById], [ModifiedDate] , [Name], [Description], [Value], [DataType]) Values ( @UserId, GETDATE(), @Name, @Description, @Value, @DataType ) -- Insert was successful so return the Inserted rowversion value Select @Id = [Common].[ApplicationParameter].[Id], @RowVersion = [Common].[ApplicationParameter].[RowVersion] From [Common].[ApplicationParameter] Where[Common].[ApplicationParameter].[Id] = SCOPE_IDENTITY() END TRY BEGIN CATCH -- Get the ErrorNumber Set @iErrorNumber = ERROR_NUMBER() --Handle Deadlock situation (Deletes, Inserts& Inserts) IF @iErrorNumber = 1205 BEGIN -- If we have not made enough attempts to break the lock IF @IdeadLockRetries< Common.fnMaxDeadlockRetries() BEGIN -- Increment the Attempt count SET @IdeadLockRetries = @IdeadLockRetries + 1 -- Pause to allow the deadlock contention to clear WAITFOR DELAY @dtDeadlockSleepInterval GOTO RETRY END END -- Handle Lock Timeout situation (Deletes, Inserts& Inserts) IF @iErrorNumber = 1222 BEGIN -- If we have not made enough attempts to break the Deadlock IF @iLockTimeoutRetries< Common.fnMaxLockTimeoutRetries() BEGIN -- Increment the Attempt count SET @iLockTimeoutRetries = @iLockTimeoutRetries + 1 -- Pause to allow the lock contention to clear WAITFOR DELAY @dtLockTimeoutSleepInterval GOTO RETRY END END --Let the Error bubble Up exec Common.RethrowError END CATCH END
SQL Server Deadlock on Insert
Hi all, I am currently trying to improve the template code in our stored proc generator. In the insert stored proc, there seems to be a lot of code with references to deadlock detection, and attempts to re-run the insert if it fails due to a deadlock. But the insert statement itself has a ROWLOCK hint on it. (See example below) So I can't see how it could possibly get a deadlock if the row hasn't previously existed. Although that said, if it was escalated to a table lock in the context of a much larger transaction perhaps it could happen. What do people do with respect to dead lock detection in their stored procs? Regards, Tony ALTER PROCEDURE [Common].[ApplicationParameterInsert] @Id int output, @Name nvarchar(50), @Description nvarchar(255), @Value nvarchar(255), @DataType nvarchar(50), @UserId uniqueIdentifier, @RowVersion rowversion output AS BEGIN -- SET DEFAULT BEHAVIOR SET NOCOUNT ON -- Performance: stops rows affected messages SET DEADLOCK_PRIORITY LOW -- This SP to be the Deadlock victim -- Initialise Lock-Timeout and Deadlock vars for Insert DECLARE @iLockTimeoutRetries as int DECLARE @IdeadLockRetries as int DECLARE @dtLockTimeoutSleepInterval as datetime DECLARE @dtDeadlockSleepInterval as datetime DECLARE @iErrorNumber as int SET @iLockTimeoutRetries = 0 SET @IdeadLockRetries = 0 SET @dtLockTimeoutSleepInterval = Common.fnLockTimeoutSleepInterval() SET @dtDeadlockSleepInterval= Common.fnDeadlockSleepInterval() SET @iErrorNumber = 0 RETRY: BEGIN TRY -- Insert Record Insert Into [Common].[ApplicationParameter] WITH (ROWLOCK) ( [ModifiedById], [ModifiedDate] , [Name], [Description], [Value], [DataType]) Values ( @UserId, GETDATE(), @Name, @Description, @Value, @DataType ) -- Insert was successful so return the Inserted rowversion value Select @Id = [Common].[ApplicationParameter].[Id], @RowVersion = [Common].[ApplicationParameter].[RowVersion] From [Common].[ApplicationParameter] Where[Common].[ApplicationParameter].[Id] = SCOPE_IDENTITY() END TRY BEGIN CATCH -- Get the ErrorNumber Set @iErrorNumber = ERROR_NUMBER() --Handle Deadlock situation (Deletes, Inserts & Inserts) IF @iErrorNumber = 1205 BEGIN -- If we have not made enough attempts to break the lock IF @IdeadLockRetries < Common.fnMaxDeadlockRetries() BEGIN -- Increment the Attempt count SET @IdeadLockRetries = @IdeadLockRetries + 1 -- Pause to allow the deadlock contention to clear WAITFOR DELAY @dtDeadlockSleepInterval GOTO RETRY END END -- Handle Lock Timeout situation (Deletes, Inserts & Inserts) IF @iErrorNumber = 1222 BEGIN -- If we have not made enough attempts to break the Deadlock IF @iLockTimeoutRetries < Common.fnMaxLockTimeoutRetries() BEGIN -- Increment the Attempt count SET @iLockTimeoutRetries = @iLockTimeoutRetries + 1 -- Pause to allow the lock contention to clear WAITFOR DELAY @dtLockTimeoutSleepInterval GOTO RETRY END END --Let the Error bubble Up exec Common.RethrowError END CATCH END
Positions available - C#.NET Dev Team Lead + 2 x Devs
Guys, I have created 3 permanent full time positions in sunny Brisbane: 1 x Team Lead, 2 x Analyst/Developers Required: - Extensive experience in C#.Net Winforms (3.5) - Experience in SQL 2005/2008 - Experience in fully SDLC, inc Business Requirement Analysis - Strong customer focus - High performer Preferred: - Experience using PLINQO (CodeSmith) - Healthcare sector experience September start. Salary commensurate with skill and experience. Please pass this on to anyone you think would be interested. Cheers Shai
RE: Remote debugging outside of domain
No luck. Same result. Liked the idea though. I also made sure that the user was in the VS remote debugger permissions and they had debugging permissions under the local security policies. - Michael Lyons -Original Message- From: Ken Schaefer [mailto:k...@adopenstatic.com] Sent: Sunday, 8 August 2010 9:50 PM To: Michael Lyons Subject: RE: Remote debugging outside of domain One option to try: Connect to shared folder on the remote machine first (e.g. c$ admin share) using Explorer Then VS. NET might use your established credentials to attempt to connect to the remote debugger service Cheers Ken -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Michael Lyons Sent: Sunday, 8 August 2010 8:03 PM To: 'ozDotNet' Subject: Remote debugging outside of domain I'm needing to debug a Windows service to see why it is crashing after a few minutes. I've setup the remote debugger on the host machine, but I receive the error message "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'x'. Logon Failure: unknown username or bad password". The issue is that my workstation is within a AD domain whilst the machine I wish to debug is not. How can I go about debugging the remote machine without disconnecting from the domain or connecting the remote machine to the domain? The service has also for some reason or another stopped outputting to via System.Diagnostics.EventLogTraceListener, would anyone have any clue why this would happen? - Michael Lyons
RE: Remote debugging outside of domain
> Is the trace option turned off in the app.config? Do you mean have I setup the system.diagnostics section; then yes I have as below. I haven't however used the trace options which are part of system.web as I'm sure you don't need these in a windows service, please correct me though if I am wrong. - Michael Lyons -Original Message- From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Richards Sent: Monday, 9 August 2010 8:03 AM To: ozDotNet Subject: Re: Remote debugging outside of domain Have you tried logging on with credentials from the remote computer? ie, create a local "testuser" account on the remote server and log on with "remoteserver\testuser". Is the trace option turned off in the app.config? David "If we can hit that bullseye, the rest of the dominoes will fall like a house of cards... checkmate!" -Zapp Brannigan, Futurama On Sun, Aug 8, 2010 at 20:02, Michael Lyons wrote: > I'm needing to debug a Windows service to see why it is crashing after a few > minutes. > I've setup the remote debugger on the host machine, but I receive the error > message "Unable to connect to the Microsoft Visual Studio Remote Debugging > Monitor named 'x'. Logon Failure: unknown username or bad password". > The issue is that my workstation is within a AD domain whilst the machine I > wish to debug is not. How can I go about debugging the remote machine > without disconnecting from the domain or connecting the remote machine to > the domain? > > The service has also for some reason or another stopped outputting to via > System.Diagnostics.EventLogTraceListener, would anyone have any clue why > this would happen? > > - > Michael Lyons > >
Re: Remote debugging outside of domain
Have you tried logging on with credentials from the remote computer? ie, create a local "testuser" account on the remote server and log on with "remoteserver\testuser". Is the trace option turned off in the app.config? David "If we can hit that bullseye, the rest of the dominoes will fall like a house of cards... checkmate!" -Zapp Brannigan, Futurama On Sun, Aug 8, 2010 at 20:02, Michael Lyons wrote: > I'm needing to debug a Windows service to see why it is crashing after a few > minutes. > I've setup the remote debugger on the host machine, but I receive the error > message "Unable to connect to the Microsoft Visual Studio Remote Debugging > Monitor named 'x'. Logon Failure: unknown username or bad password". > The issue is that my workstation is within a AD domain whilst the machine I > wish to debug is not. How can I go about debugging the remote machine > without disconnecting from the domain or connecting the remote machine to > the domain? > > The service has also for some reason or another stopped outputting to via > System.Diagnostics.EventLogTraceListener, would anyone have any clue why > this would happen? > > - > Michael Lyons > >
Remote debugging outside of domain
I'm needing to debug a Windows service to see why it is crashing after a few minutes. I've setup the remote debugger on the host machine, but I receive the error message "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'x'. Logon Failure: unknown username or bad password". The issue is that my workstation is within a AD domain whilst the machine I wish to debug is not. How can I go about debugging the remote machine without disconnecting from the domain or connecting the remote machine to the domain? The service has also for some reason or another stopped outputting to via System.Diagnostics.EventLogTraceListener, would anyone have any clue why this would happen? - Michael Lyons
Re: Extensible Storage Engine
On Sun, Aug 8, 2010 at 5:23 PM, Greg Keogh wrote: [...] > I am quite sure that I will use managed ESENT in real apps quite soon. Like > UDP and T4, I reckon it’s one of those hidden gems. What is UDP? Or are you referring to the protocol? > Greg -- silky http://dnoondt.wordpress.com/ "Every morning when I wake up, I experience an exquisite joy — the joy of being this signature."
RE: Extensible Storage Engine
I wanted to do a tech.ed talk on ESE but it was rejectedah, what might have been. Ah! The pillocks. Anyway, I've read the samples, some of the source code and some of the documentation and I think they CodePlex team have done a really neat job on wrapping esent.dll in a friendly way that has a nice .NET coding style. You can "quick start" with the generic dictionary which has ESE as the backing store, or you can use the Api.XXX methods and disposable class wrappers. I can see now that ESE is a rather classical ISAM implementation. You have familiar tables and columns with indexes and you can search EQ, GE or LE and read sequentially, but not much more than that. It really takes me back to mainframe ISAM (and VSAM) files, which in their day were pretty powerful and we built a lot of gigantic applications over them. I remember going to a database conference in 1986 and the hot subject was this new fangled thing called relational databases. I am quite sure that I will use managed ESENT in real apps quite soon. Like UDP and T4, I reckon it's one of those hidden gems. Greg
