Options

Field ID - Renumbering tool

navimbsnavimbs Member Posts: 137
I am facing a problem at the client side. We have done the merging for location A(at country A) from HQ. We have moved & merged the objects from HQ to A. A & HQ is a LS Retail database at ver 4.0 SP3.

While merging, we had to move some fields from 99........xx to 50000-99999 range.

My question is:-
1. Will these fields moved from 99...xx location to 50k...99k range will create problems?
2. Will the above create problem when the user starts testing a functionality that is using these objects?
3. Is it that when the transfer is from a lower to higher version, this movement is not advised?
4. Is there a need for using renumbering tool?
5. The client wants to import the setups from Master db at HQ to the Merged database at A. ***Is there a way that the user can import the setups from Master db(HQ) to the merged location A(A database)?

[We do data upgrade in upgrade. But there is not usual practice to import data when merging is done. This is because the fields get disturbed]

Kindly respond with your answers to these points.

Anticipating an early response,

Thanks in advance,

Best regards,

Comments

  • Options
    DenSterDenSter Member Posts: 8,304
    I'm not sure I understand what you are saying. If you are talking about renumbering fields from an LS database to the 50K range then yes that is a huge problem, because LS is a product that needs to be purchased. The correct way to get into your database is to have those numbers added to your license, not to put their code into custom numbers.
  • Options
    ara3nara3n Member Posts: 9,256
    There is a thread on merging two different addons.

    http://www.mibuso.com/forum/viewtopic.php?t=22134
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • Options
    navimbsnavimbs Member Posts: 137
    Thanks,

    I will try to clarify again:-
    HQ(A) LS Retail db was in 4.0.1 version while Location(B) database was in 4.0.2 version. Objects were migrated & merged from A to B.

    Client wanted to import the Setups from the MASTER database to the respective location database(merged).
    To do this, the user took the data backup of Master database and tried to import to the Merged db. This created error because the keys were moved to other series.

    =>> They need a facility to make the export of all setups from the Master database & import to respective location databases.

    =>>Client have a concern that since the keys are moved to 50k-99k series on merging, it will create problem in functionality testing. They have not been able to test the system since the import of setups from Master db had thrown error.

    Please suggest the right solution....

    Thanks in advance.
  • Options
    DenSterDenSter Member Posts: 8,304
    You will probably have to create one set of dataports to export the data from database A, and another to import into database B. You could get fancy and use variables in the dataport, and map to different fields depending on whether you're importing or exporting, but I think plain sets of dataports will work best in this case.
  • Options
    navimbsnavimbs Member Posts: 137
    Thanks.

    To correct on the above, we have A at a higher version & B(merged database) at a lower version.

    Dataport is the right solution, this helps. But i am still questioned, as there would be lot of setups involved. How many such dataports will need to be constructed to import all setups?

    Thanks in advance.
  • Options
    DenSterDenSter Member Posts: 8,304
    That is an impossible question for someone who does not know your setup. You can create one dataport per table, you can also create a dataport with more than one table. Any combination could work, it all depends on what you feel comfortable with.

    Good luck :mrgreen:
Sign In or Register to comment.