Showing posts with label bug. Show all posts
Showing posts with label bug. Show all posts

Thursday, March 22, 2012

Difference between 2000 and 2005. Maybe a bug?

I’m having a problem with a piece of sql and the way it is interpreted in SQL
Server 2000 and SQL Server 2005. Here is a table definition:
if not exists
(select 1 from sysobjects where uid = user_id() and type = 'U' and name
= 'rpt_Parameter')
CREATE TABLE rpt_Parameter
(
idrpt_Parameter integer IDENTITY,
idrpt_UserReport integer NOT NULL,
szParameterName nvarchar(255) NOT NULL,
szParameterValue nvarchar(2000) NOT NULL
)
go
if not exists
(select 1 from sysobjects o, information_schema.constraint_table_usage c
where o.uid = user_id() and o.type = 'K' and o.name = 'rpt_Parameter_KEY'
and o.name = c.constraint_name and c.table_name = 'rpt_Parameter' and
c.table_schema = user_name())
ALTER TABLE rpt_Parameter ADD
CONSTRAINT rpt_Parameter_KEY
PRIMARY KEY CLUSTERED (idrpt_Parameter)
Go
As part of a software upgrade we execute the following SQL
Update rpt_parameter
Set szParameterValue = '999999999999'
Where szParameterName in ('AdjCostEnd', 'ChargeCostEnd')
And convert(decimal(16,4),szParameterValue) > 999999999999
GO
In SQL Server 2000 this executed fine. In SQL Server 2005 I get the
following error:
“Error converting data type nvarchar to numeric”
Everywhere in the table where the szParameterName meets the values in the
where clause the values are indeed numeric but there are other entries where
they are not. It seems like the DB engine is not performing that part of the
where before doing the convert which results in the error. I rechecked BOL
and the precedence should be left to right. I’ve tried reworking the
statement several ways even adding an extra IsNumeric check and enclosing the
entire where clause in parenthesis but the result is always the error. I
have been able to get around it by first selecting the correct rows based on
the szParameterName value into an inline table and then joining on that for
the convert but it seems really clumsy to do that.
Could this be a bug? I searched the forum for similar things and did find
one post about a date conversion problem but didn’t find anything else?
Thanks in advance for any help.
Wayne
On Thu, 19 Jan 2006 13:09:04 -0800, Wayne wrote:
(snip)
>As part of a software upgrade we execute the following SQL
>Update rpt_parameter
>Set szParameterValue = '999999999999'
>Where szParameterName in ('AdjCostEnd', 'ChargeCostEnd')
>And convert(decimal(16,4),szParameterValue) > 999999999999
>GO
>In SQL Server 2000 this executed fine. In SQL Server 2005 I get the
>following error:
>Error converting data type nvarchar to numeric
Hi Wayne,
This is not a bug. The optimizer is free to evaluate the conditions in
any order it sees fit, just as long as it doesn't affect the output it
produces. Now you may say that in this case it does affect the output,
but situations like this (with data that may throw errors) are
explicitly exempted from that rule.
A possible workaround is to use a CASE, where the order of evaluation is
guaranteed:
WHERE CASE WHEN szParameterName in ('AdjCostEnd', 'ChargeCostEnd')
THEN convert(decimal(16,4),szParameterValue)
ELSE 0.0
END > 999999999999.0
Hugo Kornelis, SQL Server MVP
|||Hi Hugo,
Thank you very much. I tried you example and it works, but I bet you knew
that :-) I guess I'll have to remember to think about it in that way when
making a where clause that could have invalid output when evaluating it. But
the behavior change between 2000 and 2005 was sure a surprise. Thanks again
for your help.
Wayne
"Hugo Kornelis" wrote:

> On Thu, 19 Jan 2006 13:09:04 -0800, Wayne wrote:
> (snip)
> Hi Wayne,
> This is not a bug. The optimizer is free to evaluate the conditions in
> any order it sees fit, just as long as it doesn't affect the output it
> produces. Now you may say that in this case it does affect the output,
> but situations like this (with data that may throw errors) are
> explicitly exempted from that rule.
> A possible workaround is to use a CASE, where the order of evaluation is
> guaranteed:
> WHERE CASE WHEN szParameterName in ('AdjCostEnd', 'ChargeCostEnd')
> THEN convert(decimal(16,4),szParameterValue)
> ELSE 0.0
> END > 999999999999.0
> --
> Hugo Kornelis, SQL Server MVP
>
sql

Difference between 2000 and 2005. Maybe a bug?

Iâ'm having a problem with a piece of sql and the way it is interpreted in SQL
Server 2000 and SQL Server 2005. Here is a table definition:
if not exists
(select 1 from sysobjects where uid = user_id() and type = 'U' and name
= 'rpt_Parameter')
CREATE TABLE rpt_Parameter
(
idrpt_Parameter integer IDENTITY,
idrpt_UserReport integer NOT NULL,
szParameterName nvarchar(255) NOT NULL,
szParameterValue nvarchar(2000) NOT NULL
)
go
if not exists
(select 1 from sysobjects o, information_schema.constraint_table_usage c
where o.uid = user_id() and o.type = 'K' and o.name = 'rpt_Parameter_KEY'
and o.name = c.constraint_name and c.table_name = 'rpt_Parameter' and
c.table_schema = user_name())
ALTER TABLE rpt_Parameter ADD
CONSTRAINT rpt_Parameter_KEY
PRIMARY KEY CLUSTERED (idrpt_Parameter)
Go
As part of a software upgrade we execute the following SQL
Update rpt_parameter
Set szParameterValue = '999999999999'
Where szParameterName in ('AdjCostEnd', 'ChargeCostEnd')
And convert(decimal(16,4),szParameterValue) > 999999999999
GO
In SQL Server 2000 this executed fine. In SQL Server 2005 I get the
following error:
â'Error converting data type nvarchar to numericâ'
Everywhere in the table where the szParameterName meets the values in the
where clause the values are indeed numeric but there are other entries where
they are not. It seems like the DB engine is not performing that part of the
where before doing the convert which results in the error. I rechecked BOL
and the precedence should be left to right. Iâ've tried reworking the
statement several ways even adding an extra IsNumeric check and enclosing the
entire where clause in parenthesis but the result is always the error. I
have been able to get around it by first selecting the correct rows based on
the szParameterName value into an inline table and then joining on that for
the convert but it seems really clumsy to do that.
Could this be a bug? I searched the forum for similar things and did find
one post about a date conversion problem but didnâ't find anything else?
Thanks in advance for any help.
WayneOn Thu, 19 Jan 2006 13:09:04 -0800, Wayne wrote:
(snip)
>As part of a software upgrade we execute the following SQL
>Update rpt_parameter
>Set szParameterValue = '999999999999'
>Where szParameterName in ('AdjCostEnd', 'ChargeCostEnd')
>And convert(decimal(16,4),szParameterValue) > 999999999999
>GO
>In SQL Server 2000 this executed fine. In SQL Server 2005 I get the
>following error:
>?Error converting data type nvarchar to numeric?
Hi Wayne,
This is not a bug. The optimizer is free to evaluate the conditions in
any order it sees fit, just as long as it doesn't affect the output it
produces. Now you may say that in this case it does affect the output,
but situations like this (with data that may throw errors) are
explicitly exempted from that rule.
A possible workaround is to use a CASE, where the order of evaluation is
guaranteed:
WHERE CASE WHEN szParameterName in ('AdjCostEnd', 'ChargeCostEnd')
THEN convert(decimal(16,4),szParameterValue)
ELSE 0.0
END > 999999999999.0
--
Hugo Kornelis, SQL Server MVP|||Hi Hugo,
Thank you very much. I tried you example and it works, but I bet you knew
that :-) I guess I'll have to remember to think about it in that way when
making a where clause that could have invalid output when evaluating it. But
the behavior change between 2000 and 2005 was sure a surprise. Thanks again
for your help.
Wayne
"Hugo Kornelis" wrote:
> On Thu, 19 Jan 2006 13:09:04 -0800, Wayne wrote:
> (snip)
> >As part of a software upgrade we execute the following SQL
> >
> >Update rpt_parameter
> >Set szParameterValue = '999999999999'
> >Where szParameterName in ('AdjCostEnd', 'ChargeCostEnd')
> >And convert(decimal(16,4),szParameterValue) > 999999999999
> >GO
> >
> >In SQL Server 2000 this executed fine. In SQL Server 2005 I get the
> >following error:
> >â'Error converting data type nvarchar to numericâ'
> Hi Wayne,
> This is not a bug. The optimizer is free to evaluate the conditions in
> any order it sees fit, just as long as it doesn't affect the output it
> produces. Now you may say that in this case it does affect the output,
> but situations like this (with data that may throw errors) are
> explicitly exempted from that rule.
> A possible workaround is to use a CASE, where the order of evaluation is
> guaranteed:
> WHERE CASE WHEN szParameterName in ('AdjCostEnd', 'ChargeCostEnd')
> THEN convert(decimal(16,4),szParameterValue)
> ELSE 0.0
> END > 999999999999.0
> --
> Hugo Kornelis, SQL Server MVP
>

Difference between 2000 and 2005. Maybe a bug?

I’m having a problem with a piece of sql and the way it is interpreted in
SQL
Server 2000 and SQL Server 2005. Here is a table definition:
if not exists
(select 1 from sysobjects where uid = user_id() and type = 'U' and name
= 'rpt_Parameter')
CREATE TABLE rpt_Parameter
(
idrpt_Parameter integer IDENTITY,
idrpt_UserReport integer NOT NULL,
szParameterName nvarchar(255) NOT NULL,
szParameterValue nvarchar(2000) NOT NULL
)
go
if not exists
(select 1 from sysobjects o, information_schema.constraint_table_usage c
where o.uid = user_id() and o.type = 'K' and o.name = 'rpt_Parameter_KEY'
and o.name = c.constraint_name and c.table_name = 'rpt_Parameter' and
c.table_schema = user_name())
ALTER TABLE rpt_Parameter ADD
CONSTRAINT rpt_Parameter_KEY
PRIMARY KEY CLUSTERED (idrpt_Parameter)
Go
As part of a software upgrade we execute the following SQL
Update rpt_parameter
Set szParameterValue = '999999999999'
Where szParameterName in ('AdjCostEnd', 'ChargeCostEnd')
And convert(decimal(16,4),szParameterValue) > 999999999999
GO
In SQL Server 2000 this executed fine. In SQL Server 2005 I get the
following error:
“Error converting data type nvarchar to numeric”
Everywhere in the table where the szParameterName meets the values in the
where clause the values are indeed numeric but there are other entries where
they are not. It seems like the DB engine is not performing that part of th
e
where before doing the convert which results in the error. I rechecked BOL
and the precedence should be left to right. I’ve tried reworking the
statement several ways even adding an extra IsNumeric check and enclosing th
e
entire where clause in parenthesis but the result is always the error. I
have been able to get around it by first selecting the correct rows based on
the szParameterName value into an inline table and then joining on that for
the convert but it seems really clumsy to do that.
Could this be a bug? I searched the forum for similar things and did find
one post about a date conversion problem but didn’t find anything else?
Thanks in advance for any help.
WayneOn Thu, 19 Jan 2006 13:09:04 -0800, Wayne wrote:
(snip)
>As part of a software upgrade we execute the following SQL
>Update rpt_parameter
>Set szParameterValue = '999999999999'
>Where szParameterName in ('AdjCostEnd', 'ChargeCostEnd')
>And convert(decimal(16,4),szParameterValue) > 999999999999
>GO
>In SQL Server 2000 this executed fine. In SQL Server 2005 I get the
>following error:
>Error converting data type nvarchar to numeric
Hi Wayne,
This is not a bug. The optimizer is free to evaluate the conditions in
any order it sees fit, just as long as it doesn't affect the output it
produces. Now you may say that in this case it does affect the output,
but situations like this (with data that may throw errors) are
explicitly exempted from that rule.
A possible workaround is to use a CASE, where the order of evaluation is
guaranteed:
WHERE CASE WHEN szParameterName in ('AdjCostEnd', 'ChargeCostEnd')
THEN convert(decimal(16,4),szParameterValue)
ELSE 0.0
END > 999999999999.0
Hugo Kornelis, SQL Server MVP|||Hi Hugo,
Thank you very much. I tried you example and it works, but I bet you knew
that :-) I guess I'll have to remember to think about it in that way when
making a where clause that could have invalid output when evaluating it. Bu
t
the behavior change between 2000 and 2005 was sure a surprise. Thanks again
for your help.
Wayne
"Hugo Kornelis" wrote:

> On Thu, 19 Jan 2006 13:09:04 -0800, Wayne wrote:
> (snip)
> Hi Wayne,
> This is not a bug. The optimizer is free to evaluate the conditions in
> any order it sees fit, just as long as it doesn't affect the output it
> produces. Now you may say that in this case it does affect the output,
> but situations like this (with data that may throw errors) are
> explicitly exempted from that rule.
> A possible workaround is to use a CASE, where the order of evaluation is
> guaranteed:
> WHERE CASE WHEN szParameterName in ('AdjCostEnd', 'ChargeCostEnd')
> THEN convert(decimal(16,4),szParameterValue)
> ELSE 0.0
> END > 999999999999.0
> --
> Hugo Kornelis, SQL Server MVP
>

Sunday, March 11, 2012

Diagramming Print bug

Can someone tell me where to turn in bugs for SQL server?
I'm using the MS SQL Server Management Studio and when I change my table to
custom view and print them, they are printing funny. I can send the
printout to someone if needed.
Thanks!
Velvet
http://connect.microsoft.com/SQLServer
Regards,
Dave Patrick ...Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect
"Velvet" wrote:
> Can someone tell me where to turn in bugs for SQL server?
> I'm using the MS SQL Server Management Studio and when I change my table
> to custom view and print them, they are printing funny. I can send the
> printout to someone if needed.
> Thanks!
> Velvet
>
|||Hello Velvet,
Yes. You could submit via the link
http://connect.microsoft.com/SQLServer
I'd like to know if the version of SQL you installed? Did you apply SP1 or
SP2 CTP on the machine. You may let me know the exact reproduce steps and
send the screen shot you see to me. Plesase remove "online" in my email
address.
I look forward to your reply. Thank you!
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications
<http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx>.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
<http://msdn.microsoft.com/subscriptions/support/default.aspx>.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Velvet (MSDNNospam216@.nospam.nospam) writes:
> Can someone tell me where to turn in bugs for SQL server?
> I'm using the MS SQL Server Management Studio and when I change my table
> to custom view and print them, they are printing funny. I can send the
> printout to someone if needed.
I found a couple of bugs on diagram printing:
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=183815
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=124922
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=124788
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=124760
Looks like there is little hope for fixes in service packs.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
|||Hello Velvet,
I'm still interested in this issue. If you'd like to provide the related
information, please feel free to send me an email. We look forward to
hearing from you.
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== ====
|||Sorry, snow days up here where we are not used to getting snow... (Northwest
Washington)
I'm not quite sure I know how to tell you to repro the problem since it
happens on all of my diagrams. I have my tables in 'Table View' -- >
'Custom'. Columns showing are Column Name, Condensed Type, Allow Nulls, and
Identity.
The first one I printed only had two tables on it and was on one page. The
first few columns did not list the colum names where they were supposed to
be and I ended up having to write them in for my meeting. I still have this
one... It looks like the corner of somethign is covering it up and it's
shadded and has a double border. This only happened on one of the tables.,
the other table is fine except that where I would expect it to be blank, the
shading and border shows up at the bottom under the column.
On my bigger diagram, I didn't have to write anything in, but again where
there should be blank space along the right and bottom and there's some sort
of graphic trying to come through. It's very strange.
I saved it to a *.mdi file and I will forward it to you.
Here's my Management Studio info:
Microsoft SQL Server Management Studio 9.00.2047.00
Microsoft Analysis Services Client Tools 2005.090.2047.00
Microsoft Data Access Components (MDAC) 2000.085.1117.00
(xpsp_sp2_rtm.040803-2158)
Microsoft MSXML 2.6 3.0 4.0 5.0 6.0
Microsoft Internet Explorer 7.0.5730.11
Microsoft .NET Framework 2.0.50727.42
Operating System 5.1.2600
Thanks,
Velvet
"Peter Yang [MSFT]" <petery@.online.microsoft.com> wrote in message
news:vLisdrfNHHA.2024@.TK2MSFTNGHUB02.phx.gbl...
> Hello Velvet,
> I'm still interested in this issue. If you'd like to provide the related
> information, please feel free to send me an email. We look forward to
> hearing from you.
> Best Regards,
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Partner Support
>
> ================================================== ===
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> ================================================== ====
>

Friday, March 9, 2012

Diagram bug in 2005 Developer edition

I have a few databases which were created using sql server 2000 developer
edition. I copied them to the directory where the sql server 2005 databases
are located. I used "Attach" by right clicking on databases and attached the
databases. When I went to view the diagrams, I got a message that database
diagram support can not be installed because the database does not have a
valid user. Strange I thought since I'm using a laptop and everything else
was installed under the same Windows XP login. So I changed the owner to 'sa
'
and I got the same error message. I fixed the problem by changing the
compatability from 8.0 to 9.0. I did not change the owner on the other
databases that I attached. I got a message for sql server to install object
support, I had it install it and then I could view the diagrams just fine.I don't know if it's considered a bug but it is documented
in the read me file - ReadMeSQL2005.htm which should be off
the root of your installation media. I believe the next
update to BOL will have this documented as well. In the read
me file, check section 4.8.1 titled
Considerations for Installing Database Diagram Support
-Sue
On Thu, 13 Apr 2006 10:22:01 -0700, Doctor Who
<DoctorWho@.discussions.microsoft.com> wrote:

>I have a few databases which were created using sql server 2000 developer
>edition. I copied them to the directory where the sql server 2005 databases
>are located. I used "Attach" by right clicking on databases and attached th
e
>databases. When I went to view the diagrams, I got a message that database
>diagram support can not be installed because the database does not have a
>valid user. Strange I thought since I'm using a laptop and everything else
>was installed under the same Windows XP login. So I changed the owner to 's
a'
>and I got the same error message. I fixed the problem by changing the
>compatability from 8.0 to 9.0. I did not change the owner on the other
>databases that I attached. I got a message for sql server to install object
>support, I had it install it and then I could view the diagrams just fine.

Diagram bug in 2005 Developer edition

I have a few databases which were created using sql server 2000 developer
edition. I copied them to the directory where the sql server 2005 databases
are located. I used "Attach" by right clicking on databases and attached the
databases. When I went to view the diagrams, I got a message that database
diagram support can not be installed because the database does not have a
valid user. Strange I thought since I'm using a laptop and everything else
was installed under the same windows xp login. So I changed the owner to 'sa'
and I got the same error message. I fixed the problem by changing the
compatability from 8.0 to 9.0. I did not change the owner on the other
databases that I attached. I got a message for sql server to install object
support, I had it install it and then I could view the diagrams just fine.I don't know if it's considered a bug but it is documented
in the read me file - ReadMeSQL2005.htm which should be off
the root of your installation media. I believe the next
update to BOL will have this documented as well. In the read
me file, check section 4.8.1 titled
Considerations for Installing Database Diagram Support
-Sue
On Thu, 13 Apr 2006 10:22:01 -0700, Doctor Who
<DoctorWho@.discussions.microsoft.com> wrote:
>I have a few databases which were created using sql server 2000 developer
>edition. I copied them to the directory where the sql server 2005 databases
>are located. I used "Attach" by right clicking on databases and attached the
>databases. When I went to view the diagrams, I got a message that database
>diagram support can not be installed because the database does not have a
>valid user. Strange I thought since I'm using a laptop and everything else
>was installed under the same windows xp login. So I changed the owner to 'sa'
>and I got the same error message. I fixed the problem by changing the
>compatability from 8.0 to 9.0. I did not change the owner on the other
>databases that I attached. I got a message for sql server to install object
>support, I had it install it and then I could view the diagrams just fine.

Diagnostic or debug info

I'm trying to track down a thorny bug in SqlCE that just crashes randomly without any apparent correlation with anything. I was wondering if there is any diagnostic flags/TraceListener setting/debug info that I can turn on to see if I can find any patterns.
To get as much information as possible from a SqlCe error, traverse the SqlCe error collection to get each SqlCeError, see this sample (for managed codeSmile http://msdn2.microsoft.com/en-us/library/ms174079.aspx|||
Unfortunately, the exception occurs outside my code. I cannot place a try/catch around it.

I'm just looking for diagnostics to track down the error. For example, with Linq I can turn on some debug info with:

Code Snippet

MyDataContext db = new MyDataContext (@."mydb.sdf");
db.Log = System.Console.Out;
db.Connection.StateChange+=new StateChangeEventHandler(Connection_StateChange);



Can more be done?

|||

Not much more can be done, unless you add more tracing to your code to determine the state of the app when the crash happens.

|||Maybe you are encountering on of the rare SL CE bugs, like to the one reported here: http://www.pluralsight.com/blogs/jimw/archive/2007/09/04/48361.aspx|||
Yep, it's a random AccessViolationException that kills the entire app.
|||The problem may be related to multi-threading, which would explain the randomness.

I've changed the code to guarantee a unique db connection per thread and things *seem* to work...for now.

Diagnostic or debug info

I'm trying to track down a thorny bug in SqlCE that just crashes randomly without any apparent correlation with anything. I was wondering if there is any diagnostic flags/TraceListener setting/debug info that I can turn on to see if I can find any patterns.
To get as much information as possible from a SqlCe error, traverse the SqlCe error collection to get each SqlCeError, see this sample (for managed codeSmile http://msdn2.microsoft.com/en-us/library/ms174079.aspx|||
Unfortunately, the exception occurs outside my code. I cannot place a try/catch around it.

I'm just looking for diagnostics to track down the error. For example, with Linq I can turn on some debug info with:

Code Snippet

MyDataContext db = new MyDataContext (@."mydb.sdf");
db.Log = System.Console.Out;
db.Connection.StateChange+=new StateChangeEventHandler(Connection_StateChange);



Can more be done?

|||

Not much more can be done, unless you add more tracing to your code to determine the state of the app when the crash happens.

|||Maybe you are encountering on of the rare SL CE bugs, like to the one reported here: http://www.pluralsight.com/blogs/jimw/archive/2007/09/04/48361.aspx|||
Yep, it's a random AccessViolationException that kills the entire app.
|||The problem may be related to multi-threading, which would explain the randomness.

I've changed the code to guarantee a unique db connection per thread and things *seem* to work...for now.

Diagnostic or debug info

I'm trying to track down a thorny bug in SqlCE that just crashes randomly without any apparent correlation with anything. I was wondering if there is any diagnostic flags/TraceListener setting/debug info that I can turn on to see if I can find any patterns.
To get as much information as possible from a SqlCe error, traverse the SqlCe error collection to get each SqlCeError, see this sample (for managed codeSmile http://msdn2.microsoft.com/en-us/library/ms174079.aspx|||
Unfortunately, the exception occurs outside my code. I cannot place a try/catch around it.

I'm just looking for diagnostics to track down the error. For example, with Linq I can turn on some debug info with:

Code Snippet

MyDataContext db = new MyDataContext (@."mydb.sdf");
db.Log = System.Console.Out;
db.Connection.StateChange+=new StateChangeEventHandler(Connection_StateChange);



Can more be done?

|||

Not much more can be done, unless you add more tracing to your code to determine the state of the app when the crash happens.

|||Maybe you are encountering on of the rare SL CE bugs, like to the one reported here: http://www.pluralsight.com/blogs/jimw/archive/2007/09/04/48361.aspx|||
Yep, it's a random AccessViolationException that kills the entire app.
|||The problem may be related to multi-threading, which would explain the randomness.

I've changed the code to guarantee a unique db connection per thread and things *seem* to work...for now.