Customization Maintenance (8.0 to 9.0) 2

[scuttlebuttin]

I imported our 8.0 customization package into 9.0 using Customization Maintenace with a plethora of errors (unable to apply changes to Window, Unable to resolve reference to table..., etc.).

Upon testing our customizations, I notice that most of the form modifications (text boxes, lables, columns) are there but none of the background VBA is running. When I view the underlying VBA for a modified form via Microsoft Visual Basic, the Microsoft Dynamics GP Objects in the Object Explorer pane have characters that i can't explain (i.e. ðe_ectMaintenance and ‚S_ellaneousLogEntry and ã?_icateExistingProject). Also in an ado connection class module, Option Explicit was changed to žO¨˜QExplicit.

Is this common? Any thoughts why this is happening? Most importantly, how do i resolve this?!?!?

Thank you!

 

[winthropdc]

There is a bug in the early v8.0 runtime that messes up exported packages. I think it was fixed in SP2.

Make sure you are on the latest service pack (SP5) and export your packages again.

David Musgrave [MSFT]
Senior Development Consultant
Escalation Engineer - Great Plains
Microsoft Dynamics Support - Asia Pacific

Micorosoft Dynamics (formerly Microsoft Business Solutions)

http://www.microsoft.com/Dynamics

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.

 

[Alcar]

David,

can I safely import the customizations over the ones that are already there (and maybe including that bug?)

Thanks

Daren J. Lahey
Programmer Analyst
FAQ183-874 contains Suggestions for Getting Quick and Appropriate Answers to your questions.

 

[winthropdc]

You could import over the top, but I would recommend starting with a clean slate to avoid any corruption.

Firstly, re-export after install the v8 service pack.

Look at the packages with notepad and check that the scripts are not garbled.

Then rename the .VBA files and any custom forms and reports dictionaries (eg forms.dic and reports.dic).

Then check Customisation Maintenance to make sure you have nothing left.

Then import the now fixed packages.

All done.

David Musgrave [MSFT]
Senior Development Consultant
Escalation Engineer - Great Plains
Microsoft Dynamics Support - Asia Pacific

Micorosoft Dynamics (formerly Microsoft Business Solutions)

http://www.microsoft.com/Dynamics

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.

 

[Alcar]

While I am going thruoght this process of working on these customizations... I have a question:

is it better to create a package including all your customizations and then import it on the new server? Or is it better to create single packages per customization?



Daren J. Lahey
Programmer Analyst
FAQ183-874 contains Suggestions for Getting Quick and Appropriate Answers to your questions.

 

[winthropdc]

Daren

While it is possible to manually edit a package file with notepad when you have problems, it is much easier to have the separate packages available so you can load them individually.

If I had one large package and between versions of Great Plains something changed that meant my package fails to import, I would not be able to import anything. Having separate packages will ensure that I can load all but the one part that has failed.

My recommendation is to export separate packages for each type for each customisation.

For example:

Customisation 1 Windows.package
Customisation 1 Reports.package
Customisation 1 References.package

Customisation 2 Windows.package
Customisation 2 Reports.package
Customisation 2 Modules.package

Customisation 3 Reports.package

This way you can load each customisation separately and can make sure that Modules and References are loaded first.

Hope this helps.

David Musgrave [MSFT]
Senior Development Consultant
Escalation Engineer - Great Plains
Microsoft Dynamics Support - Asia Pacific

Micorosoft Dynamics (formerly Microsoft Business Solutions)

http://www.microsoft.com/Dynamics

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.

 

[Alcar]

Thank you David.
Yes it does make more sense. I just started creating all the different packages.

I have one last question about the .package output:

as I was going through it I noticed something that appeared to be odd, to me at least:

<Component Name="frmPension" ProductId="0" Object="VBAUserForm" >
VBAUserForm "frmPension"
{
VBABinary
"4C40800005C00000000000000000EC220000 yadda yadda yadda -- binary code"

[...]

It looks like the script used binary code to represent a form???? Is this correct when using a User Form or can this be wrong interpretation during the export?



Daren J. Lahey
Programmer Analyst
FAQ183-874 contains Suggestions for Getting Quick and Appropriate Answers to your questions.

 

[winthropdc]

Dexterity forms are represented in a readable format, but a VBA UserForm is binary data. Pictures added to reports will show as binary data as well.

This is normal.

David Musgrave [MSFT]
Senior Development Consultant
Escalation Engineer - Great Plains
Microsoft Dynamics Support - Asia Pacific

Micorosoft Dynamics (formerly Microsoft Business Solutions)

http://www.microsoft.com/Dynamics

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.

 

[Alcar]

Thank you David.

Daren J. Lahey
Programmer Analyst
FAQ183-874 contains Suggestions for Getting Quick and Appropriate Answers to your questions.