When loading the 2013 yearend .msp file to GP2010 (KB2897368), the upgrade stops at the stage of “LOADING STORED PROCEDURES - Create_Requester_Procs_cursor. I didn’t receive an error message, it just stopped.
There was still activity in the SQL trace, but it seemed to be stuck on SOP. I abandoned the update, changed the .ini settings to create a DEXSQL log and restarted the update. I turned it off as soon as it stopped again.
I read this post community.dynamics.com/.../107950.aspx and became very suspicious of eConnect. We went live on a new eCommerce solution this year and this is the first service pack installed since then. I looked at the suggested fix for the posted article’s problem, but that did not apply to me. I looked in the eConnect_Out_Setup table and did not have any DOCTYPEs of ModifiedItem, so the script suggested below, did not make any changes.
Update eConnect_Out_Setup SET DATACNT = 72 where DOCTYPE = 'ModifiedItem'
In my DEXSQL log, the very last procedure was:
/* Date: 12/31/2013 Time: 21:15:57
stmt(7120920):*/
set nocount on declare @NAME varchar(100) declare @TEXT varchar(8000) declare taCreateRequesterProcs insensitive cursor for select DOCTYPE from eConnect_Out_Setup (nolock) where MAIN = 1 and DOCTYPE not like '%GetList' open taCreateRequesterProcs fetch next from taCreateRequesterProcs into @NAME while (@@fetch_status <> -1) begin if (@@fetch_status <> -2) begin select @TEXT = 'exec eConnectOutCreate '+ @NAME + ', 0' exec (@TEXT) select @TEXT = 'exec eConnectOutCreate '+ @NAME + ', 1' exec (@TEXT) select @TEXT = 'exec eConnectOutCreate '+ @NAME + ', 2' exec (@TEXT) end fetch next from taCreateRequesterProcs into @NAME end deallocate taCreateRequesterProcs
The first procedure in the log that contained the term ‘eConnect’ was:
/* Date: 12/31/2013 Time: 21:14:40
stmt(7120920):*/
if exists (select * from dbo.sysobjects where id = Object_id('.taCreateeConnectOutTemp') and type = 'P') drop proc .taCreateeConnectOutTemp
Curiously, I checked to see how many lines included the phrase “stmt(7120920):*/”. There were 14,876 lines, out of a total 123,482 lines in the dexsql.log.
I can run the statements one at a time without error, but I don’t know what is supposed to happen later or how to get the upgrade to stop sticking.
Anybody have any ideas?
Kind regards,
Leslie
*This post is locked for comments