I process de DB with Database Maintenance tu upgrade from SL7 to SL7 FP1 Sp4.
All the process without errors.
But when i start Ms Dynamics a extrange message apears at then bottom window:
"Reliance on preliminary conversion databases may result in the loss of production data and/or additional time or expense in correcting the data. MICROSOFT MAKES NO WARRANTY OF ANY KIND WHATSOEVER, EXPRESS OR IMPLIED, REGARDING PRELIMINARY CONVERSION DATABASE(S). ANY AND ALL WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED AND EXCLUDED BY MICROSOFT. IN NO EVENT SHALL MICROSOFT BE LIABLE TO YOU, AS LICENSEE, OR ANY OTHER PERSON FOR ANY SPECIAL, INDIRECT, CONSEQUENTIAL OR INCIDENTAL DAMAGES (INCLUDING DAMAGES FOR BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION OR SIMILAR LOSSES) EVEN IF MICROSOFT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Microsoft is not responsible for any loss of production data or business information, nor is it responsible for additional time and expense incurred in the correction and certification of any preliminary conversion database. Please contact Technical Support immediately if this message is displayed."
This was the "production" database. I don´t undersatnd what happends and how quit this msg.
Thanks in advance for any help!!!
PD: I re-register all the modules. I have 47 and the licences for 47 correctly ingresed...
So... you have to prepare some tables after the upgrade (from SL7.00 to SL7.03 FP1 Sp4).
You have to check in all tables where Crtd_User = '(PC)' (I have a sql script that do that job for me) Then... UPDATE then to something like this Crtd_User = 'UPGRADE' (or whatever) (Just in case, maybe not necesary at all, I updated Crtd_prog = 'SolFFTW' to Crtd_prog = 'HEINLEIN' (or whatever too)
Then I process de database with Database Maintenance with the option: "6.5x, 7.x to 7.0 SP4"
And the apocalyptic message just "go away"....
PD: I Updated this tables:
UPDATE Vendor SET Crtd_User = 'UPGRADE' where crtd_user = '(PC)'
UPDATE CuryRate SET Crtd_User = 'UPGRADE' where crtd_user = '(PC)'
UPDATE POAddress SET Crtd_User = 'UPGRADE' where crtd_user = '(PC)'
UPDATE Terms SET Crtd_User = 'UPGRADE' where crtd_user = '(PC)'
UPDATE Vendor SET Crtd_prog = 'HEINLEIN' where Crtd_prog = 'SolFFTW'
UPDATE CuryRate SET Crtd_prog = 'HEINLEIN' where Crtd_prog = 'SolFFTW'
UPDATE POAddress SET Crtd_prog = 'HEINLEIN' where Crtd_prog = 'SolFFTW'
UPDATE Terms SET Crtd_prog = 'HEINLEIN' where Crtd_prog = 'SolFFTW'
PD2: MsDynamicsSL.EXE searches at least in this tables:
SELECT COUNT(*) FROM GLSetup (nolock) WHERE crtd_user = '(PC)'
SELECT COUNT(*) FROM Account (nolock) WHERE crtd_user = '(PC)'
SELECT COUNT(*) FROM InTran (nolock) WHERE crtd_user = '(PC)'
SELECT COUNT(*) FROM Vendor (nolock) WHERE crtd_user = '(PC)'
SELECT COUNT(*) FROM CuryRate (nolock) WHERE crtd_user = '(PC)'
SELECT COUNT(*) FROM POAddress (nolock) WHERE crtd_user = '(PC)'
SELECT COUNT(*) FROM Terms (nolock) WHERE crtd_user = '(PC)'
I´ve done al the process again... with exactly the same result.
UPDATE: That message string is inside the EXE: MsDynamicsSL.exe
UPDATE2: If the registration data is loaded or not... doesn´t matter. It seems that never get there. Always start on a TRIALLOC mode ?!¡?!¡!
I believe you have a situation where you should get help from your partner or open a ticket with Microsoft. It has to do with inconsistent data and how the database might have been converted from versions previous to this attempt.
When databases were converted from 2.06 versions of Sol IV ti 4.5 or later versions, they used a Fast Forward conversion program.
The upgrade would first be done on a test copy of the database. This database was then not to be used going forward but a new current copy of the database was then used when the actual go live conversion was done. There was a charge associated with each. This was how Microsoft handled the conversions. Partners also did conversions and I don't know how they may have handled theirs.
There were certain fields that were populated in a particular way so that Microsoft knew whether someone was using the test conversion copy or not.
Once you get this message, I expect that you will have only 20 accesses before you are locked out.
To clear out the noted fields, we created another script to run against the database at the time of the live conversion.
I can not say why going from 7 fp1 to 7 fp4 would cause this message to pop up again. I think we may have experienced that a few other times with our other clients, not necessarily between these 2 versions but just in the past some time.
I need to research and get back to you tomorrow what the next step will be. If your VAR converted your database from 2.06, you will probably want to contact him first.
If you look at some of your old records, you will likely find the crtd_user will be FastFoward.
If you need assistance beyond what your VAR can provide, you will need to create a service request with Microsoft Dynamics SL support. We can then work with you to do what is needed to get this message cleared. You can create a service request by calling the support help desk at 888-477-7877. There will be a charge associated with the service request.
Thanks Elaine and Butch for your responces
SQL Profiler - Ms Dynamics SL7 Startup:
Select Crtd_User from GLSetup (nolock) where crtd_user = '(PC)'
Select Crtd_User from Account (nolock) where crtd_user = '(PC)'
Select Crtd_User from InTran (nolock) where crtd_user = '(PC)'
Select Crtd_User from Vendor (nolock) where crtd_user = '(PC)'
Maybe thats the Crtd_user of FastFoward... I update it, but nothing different happends. (Still Trialloc mode)
There is a relation between OBJECT_ID('GLSetup') and GlSetup.s4future03.
If I change de (SysObjects) Sql Id of "GlSetup" the value of GlSetup.s4Future03, changes and remains constant until the Id changes again. (Still Trialloc mode)
I´m going to create a new database for this company from DatabaseMaintenance and all the company registration (Including Licence Keys)... then I´m going to SQL copy all the data between them. Except GlSetup (App), AccessModule (sys), RegistDetail (sys), Access (sys), Company (sys), RegistItem (sys), Registration (sys), Rptextra (sys), SLData (sys) and AccessModule (sys)
If the TRIALLOC flag is another table ... all this work will be useless
* If the TRIALLOC flag is IN another table ... all this work will be useless
This might work or might not.
A support case would require you to upload your database but is the route I would advise considering time and effort involved.
You do good work!
Other Microsoft Sites
I'm a Customer
I'm a Partner
Follow Microsoft Dynamics