none
Windows Mobil – SQL- Symbol MC70 Problem

    Question

  • Have an App using SQL CE 2.0. 

     

    If the App is open and the device is powered off and then back on; the following happens when an update of the data base is attempted:

     

     

    1. Pocket PC 2003 – IPAQ    No problem all is well.

    2.  WM 2005 – Dell   No problem all is well

    3.  WM 2005 – Symbol MC70  SQL error 0x80004005.**

     

    App is compiled under eVC 4.0

     

    ** Some results if App is compiled under VS2005

     

    Is this:

     a.) My problem ?

     b.) WM 2005 problem ?

     c.) Symbol problem ?

    d.) SQLCE 2.0 problem?

     

     Any input would be appreicated

     

    Thanks

     

    JEK

    Friday, June 09, 2006 11:01 PM

Answers

  • Hi,

      We have an application which use SQL Mobile 3.0 ; and it is developped natively (c++ only). We did experienced the same problem as you described but with a Dell X51 (WM2005) and a Dell X50 (WM2003SE).

      It was really a pain since our client already deploy a pilot to 10 users and never notices it before.

      1st work-around was to forbid the device to automatically power-off :(

      Then, our 2nd work-around, inelegant for sure, was to close database connection and re-open it everytime we saw a failure to open a rowset (both using IOpenRowset and ICommandText) and getting an 0x80004005 error.

      It is more or less a working work-around.

     

      Then I saw that DBPROP_CONNECTIONSTATUS property in DBPROPSET_DATASOURCEINFO could tell us that database connection was closed but it seems that it is not supported in SQL CE 3.0 :(

      I'm sure there is a way to find, for sure, if connection to database is dropped but, for the moment, I couldn't find where...

      In .Net, there's something like ConnectionState... so it's surely somewhere...

     

      Good luck and I hope that it helps.

      Cheers,
    Fabien.

     

    BTW: it seems that our previous develoment done in SQL CE 2.0 was not affected on Dell X51 (or not too much).

    Wednesday, July 12, 2006 11:04 AM

All replies

  • Hi John,

    I'm not sure about the MC70 part of the equation, but what happens if you cache a single connection to the DB and every time you use it, check that it is not null and the connection state is opened?  Do you get the same behavior you listed above?  I have heard a few other report that on WM5 devices the connection state does not report itself correctly after a power resume and have reported this to MS.  Some people found that by waiting a few seconds after the resume, the connection state does eventually correct itself.  This didn't work for some devices though.

    Darren

     

    Saturday, June 10, 2006 6:28 PM
  •  

     

    Hi Darren

    I don't understand what you mean by >>cache a single connection<<

    The App is running stand-alone, it is not connected to anything.

    Are there any messages sent when power is about to turn of or resumed?

     JEK 

    Saturday, June 10, 2006 9:05 PM
  • What I mean is instead of creating, opening, using, and disposing of a SqlCeConnection each time you want to access the database, are you caching a single connection object and reusing it for all database operations.  Something like this:

    Public ReadOnly Property DBConnection() As SqlCeConnection

    Get

      Try

        If (_cn Is Nothing) Then

          _cn = New SqlCeConnection(_dbmsConnectionString)

          _cn.Open()

        End If

        If (_cn.State <> ConnectionState.Open) Then

          _cn.Open()

        End If

      Catch ex As SqlCeException

        DisplaySQLCEErrors(ex)

      End Try

        Return _cn

      End Get

    End Property

    the Smart Device Framework 2.0 (www.opennetcf.org) does have managed powerdown and resume events available if I remember correctly.

    Darren

     

    Saturday, June 10, 2006 9:25 PM
  •  

    We are using the OELDB Provider for SQL CE 2.0.  The COM Object is instantiated  when the App starts and stays inexistence until the App ends.

     

    We use plain ole VC COM Interface programming, and not  .NETCF, really don't understand your example.

     

    Thanks

     

    JEK

    Sunday, June 11, 2006 12:14 AM
  • Sorry John - didn't realize you were a native code developer.  You might want to post this question at microsoft.public.sqlserver.ce which is a newsgoup that JP Figueroa monitors - JP is an MVP with great experience in leveraging SQL CE and SQL Mobile from native code.  You could also do a google advanced groups search on your problem there - I seem to remember this coming up before.

    Darren

     

    Sunday, June 11, 2006 5:39 PM
  • Hi,

      We have an application which use SQL Mobile 3.0 ; and it is developped natively (c++ only). We did experienced the same problem as you described but with a Dell X51 (WM2005) and a Dell X50 (WM2003SE).

      It was really a pain since our client already deploy a pilot to 10 users and never notices it before.

      1st work-around was to forbid the device to automatically power-off :(

      Then, our 2nd work-around, inelegant for sure, was to close database connection and re-open it everytime we saw a failure to open a rowset (both using IOpenRowset and ICommandText) and getting an 0x80004005 error.

      It is more or less a working work-around.

     

      Then I saw that DBPROP_CONNECTIONSTATUS property in DBPROPSET_DATASOURCEINFO could tell us that database connection was closed but it seems that it is not supported in SQL CE 3.0 :(

      I'm sure there is a way to find, for sure, if connection to database is dropped but, for the moment, I couldn't find where...

      In .Net, there's something like ConnectionState... so it's surely somewhere...

     

      Good luck and I hope that it helps.

      Cheers,
    Fabien.

     

    BTW: it seems that our previous develoment done in SQL CE 2.0 was not affected on Dell X51 (or not too much).

    Wednesday, July 12, 2006 11:04 AM
  •  

    In case anyone is still interested.  This is a known problem with Symbol and Microsoft.  The MMC devices drivers as shipped from MS will Whack all FIle Handles when the device hiberantes.  Symbol ended up suppling their own device driver.  The problem has occured with other manufactures who also used the stock MS drivers.

    Tuesday, August 22, 2006 10:37 PM
  • A thank you John for circling back and letting the forum know about a solution on Symbol MC70.

    Appreciate you doing that.

    Darren

     

    Tuesday, August 22, 2006 11:35 PM