web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics SL (Archived)

[Microsoft][ODBC Driver Manager] Invalid cursor state

(0) ShareShare
ReportReport
Posted on by

Dear all,

I have a problem when my VBRDT screen was saved. It gave me below error.

[Microsoft][ODBC Driver Manager] Invalid cursor state

  Debugging info: SQLSetPos

  Cursor(CSR_xtREAgentMain) xsREAgentMainAll_PV  'MU001' 

  Optional info: SqlState = 24000 NativeError = 0 ErrorMsg = [Microsoft][ODBC Driver Manager] Invalid cursor state pcbErrorMsg = 53

ODBCRowNumber = -1 SSrvrLine = 63200 SSrvrMsgState = 0 SSrvrSeverity = 0 SSrvrProcname =  SSrvrSrvname = 

The condition is I have upgraded my solution from Version 7 SP 3 to 2011. My current VBRDT was developed in Visual Studio 2008. So that what I did just openend the solution in Visual Studio 2010, and let Visual Studio convert it. Did I do something mistake with the conversion ?

Actually above error happens if only the screen is opened for the first time and creates a new transaction after Dynamics SL is opened . If I just lookup it, it didn't give me any error.

 

Best Regards,

Afin

*This post is locked for comments

I have the same question (0)
  • Barry Flynn Profile Picture
    3,090 on at

    Afin

    Opening the project in VS 2009 should be sufficient - that's what I've done.

    Provided, of course, that your environment is such that you are including the SL 2011 versions of the Solomon.vbtools.vb file, and the various "DH Files".

    There is a "conversion" you can run to convert the "old" SAFDate controls to their replacement (DSLDate? Can't remember.)

    But it still runs fine if you haven't done that conversion.

    I can't think of any likely cause of this error that didn't already exist in 7.0.

    The one thing that comes to my mind is that prior to doing an Update/Insert, the Solomon cursor being used MUST have been used to do a Fetch against the same table(s).

    It doesn't matter if the Fetch retrieved any records. It simply must have been executed.

    However that has applied in VBTools for many versions.

    Barry

  • Community Member Profile Picture
    on at

    Something has changed between 2007 and 2011.  Something fundamental.  I used to be able to do this:

    Pseudocode, obviously :)

    [Figure out a key value]

    DO until not found

       SQLFetch1 (mytable...)

    LOOP

    TranBeg(true)

    Sinsert1(mytable...)

    TranEnd()

    TranBeg(true)

    Supdate1(mytable...)

    TranEnd

    If I do that now in 2011, I get an error similar to the one listed in the original post.  If I put *another* SQLFetch1 between the Sinsert and Supdate it works.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics SL (Archived)

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans