winthropdc
Programmer
For all those who understand the Index File and its role in Source Code Control and are using it, please ignore this posting.
When using Source Code Control, all resources are stored in a text representation in your repository. They are stored with their names as the unique identifier.
In your development dictionary, the unique identifier is actually the internal Resource ID generated by Dexterity. For third party developers (ie. most Dex Developers), these start at 22,000.
As you add resources (Forms, Tables, Reports, Field etc.), they are provided Resource IDs by whatever is next available. So they end up being numbered in order they were created.
When creating a new build, you would start with a base DYNAMICS.DIC and then update all your resources from the repository. During this process, resources are brought in in alphabetical order and are assigned Resource IDs as the resources are added. So now the Resource IDs are number in alphabetical order. This is going to cause problems with updating of modified forms and reports, security records for access denied or alternate windows and generally make life very difficult.
The solution is the Index File, which tracks the Resource IDs assigned to resources and ensures that they are maintained between builds.
So to use the index file....
Make sure that the Edit >> Options >> Source Control >> Enable Administrative Features is checked for the developer in charge of the build process.
Every time a build is completed, select Explorer >> Source Control >> Update Index File from the menus.
Every time a create a new build, select Explorer >> Source Control >> Update. On the Update from Repository window select the Use Index File option. In the words of Dexterity Product Manager, "Just because it is an option does not mean it is optional".
This will ensure that resource ID's stay consistant between builds and between version releases.
Hope this helps.
David Musgrave
Senior Development Consultant
Asia Pacific Professional Services
Microsoft Business Solutions
mailto:dmusgrav@nospam-microsoft.com
Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
When using Source Code Control, all resources are stored in a text representation in your repository. They are stored with their names as the unique identifier.
In your development dictionary, the unique identifier is actually the internal Resource ID generated by Dexterity. For third party developers (ie. most Dex Developers), these start at 22,000.
As you add resources (Forms, Tables, Reports, Field etc.), they are provided Resource IDs by whatever is next available. So they end up being numbered in order they were created.
When creating a new build, you would start with a base DYNAMICS.DIC and then update all your resources from the repository. During this process, resources are brought in in alphabetical order and are assigned Resource IDs as the resources are added. So now the Resource IDs are number in alphabetical order. This is going to cause problems with updating of modified forms and reports, security records for access denied or alternate windows and generally make life very difficult.
The solution is the Index File, which tracks the Resource IDs assigned to resources and ensures that they are maintained between builds.
So to use the index file....
Make sure that the Edit >> Options >> Source Control >> Enable Administrative Features is checked for the developer in charge of the build process.
Every time a build is completed, select Explorer >> Source Control >> Update Index File from the menus.
Every time a create a new build, select Explorer >> Source Control >> Update. On the Update from Repository window select the Use Index File option. In the words of Dexterity Product Manager, "Just because it is an option does not mean it is optional".
This will ensure that resource ID's stay consistant between builds and between version releases.
Hope this helps.
David Musgrave
Senior Development Consultant
Asia Pacific Professional Services
Microsoft Business Solutions
mailto:dmusgrav@nospam-microsoft.com
Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.