Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A commandlet for identifying Variable ID conflicts on the merge process? #11

Open
barandeniz opened this issue Nov 25, 2016 · 7 comments

Comments

@barandeniz
Copy link

Hello, i am getting so much variable conflicts during merges. The bad thing about this is, the conflicts being problem on the Import process. For example, when the first conflict is on %85 then i am getting the error after 15 min import process. I resolve the issue, then import again. If there is another conflict ie %88, then i have to import whole objects again in order to see another conflict. It is very time consuming process and very unproductive way to resolve a simple problem.

I wonder is there a way to identfy those conflicts before import the merged object file ?

@waldo1001
Copy link
Owner

Well .. it is quite complicated to get the variable id's out - let alone compare them (in the same context) and report duplicates.. .

The best thing I have come up with to handle this is to import all objects file-by-file. So in stead of a joined file, I split the result , and import all files (with a loop). It takes longer, but it reports all errors per object.. .

Not ideal, I know.. . but I haven't been able to put time in what you requested ..

@barandeniz
Copy link
Author

How do you import all the objects with a loop ? can you help me about this ?

@waldo1001
Copy link
Owner

Well, use Split-NAVApplicationObject to split the files.

Then, import them one-by-one by looping the files, like:
Get-ChildITem "YourFolder" | Foreach {Import-NAVApplicationObject -Source $_.FullName}

Something like that...

@rdebath
Copy link

rdebath commented Feb 16, 2017

Other notes:

  • Don't import all the objects ... you only need to import objects that are different from Cronus.
  • Split by object type ... Pages are likely to have the conflicts, but they load in fast; reports are slow to load because they need to open part of Visual studio for checks.
  • If you have a file that fails at 88% chop it into two parts 80:20.
  • When programming remember "Start ID (Uidoffset)", in Devenv->File->Database->Alter->Advanced. Put different projects in different ID ranges.

@rdebath
Copy link

rdebath commented Feb 16, 2017

Arrgh, and what I was going to say:

  • A program to renumber IDs is easier than one to detect collisions, just find all IDs and for any in the range 1000000000..1000009999 change them to completely unused ones in 1000100000 and up.

@waldo1001
Copy link
Owner

Howdo you know which ID's are completely unused ones"? As such, I'd rather say change them to your range.. .

Very true with the UIDOffSet. I have a function for that :-)
https://github.com/waldo1001/Cloud.Ready.Software.PowerShell/blob/master/PSModules/Cloud.Ready.Software.NAV/Set-NAVUidOffset.ps1

@rdebath
Copy link

rdebath commented Feb 17, 2017

I was thinking of the second time you have to do it where moving from 1000000000+N to yourid+N may create a collision. So once you have the list of all the IDs in this object (irrespective of context) if the one you would have renumbered it to is used somewhere in the object switch it to one that isn't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants