Yes! To migrate the projects forward do the following:
(Step 1) Ensure that the project is valid in the old project format. If it is not valid in the old format it surely will not convert properly to the new! Open the project in PEDDS Version 2.6 “Project >> Open”. Ensure that each signatory is valid and is used to sign file(s) in the project. If the signatory signs no files, delete it! Unused signatories are not supposed to remain in the project.
(Step 2) Run the authentication test using PEDDS Version 2.6 “Authenticate >> Project”. If the project passes the test, make a copy of the _meta_info and place it in a safe place out of the project’s folder structure (just in-case…). Proceed to step 3. Otherwise, fix the errors, re-secure the project and repeat this step.
(Step 3) Close the project and exit PEDDS Version 2.6. Delete all of the *.txt files from project _meta_info folder (the ones in the project _meta_info, not the one you saved). Open the project in PEDDS Version 3.1 “Project >> Open”. Select the root folder for the project and click “OK”.
(Step 4) Once the project is opened, check the Available Signatories drop-down list to ensure that all of the signatories are present, if there were any created with a previous version. If there are signatories, proceed to Step 5. Otherwise, skip Step 5 and go to Step 6.
(Step 5) Authenticate each of the Signatory Documents using the new production PEDDS (188.8.131.52). If there is a successful authentication on each, proceed to Step 6. If not, close the project; fix the error using the older version 2.6. and start over at Step 3.
(Step 6) Select “Project >> Modify >> Identification Information” and without changing any of the information click “Save”.
(Step 7) Select “Project >> Secure”. Review the report to ensure that there are no errors. You now have a Version 3.1 PEDDS Project.
If things go wrong and you wish to start over, you have the _meta_info folder that you saved in step 2 when you started. Clear the contents of the project _meta_info. Copy the contents of that saved _meta_info from step 2 back into the project _meta_info and you are back where you started.
For best practice, we recommend that you do not! Version 2.6 will be available for some time to come to allow projects produced in the old format to be processed with the version that they were created in. This will cause the least disruption in the production / letting process.
No! It will corrupt the project files, especially any new signatories that you created with the new PEDDS! PEDDS version 3.1 is not backward compatible with any previous version of PEDDS. Old projects can be easily migrated forward. However, once migrated they cannot be processed by any previous version of PEDDS. This will require that everyone working with the project from this point on use version 3.1 of PEDDS or a later version.
Every XML file that the new PEDDS software produces contains an application and version attribute.
If these attributes do not exist, the project is versioned at some prior release of PEDDS.
Inspect these files using internet explorer or some other read-only means.
Do not alter these files! You will corrupt your project! If they look like the examples below they are the new format.
Note that the name of the application that produced the file and the version number of that application is clearly shown.
Yes - PEDDS will still be used to SECURE a project (usually on a CD-ROM) for delivery to FDOT. The data on that CD-ROM (or other delivery media) will AUTHENTICATED as original using PEDDS. Signing / Sealing is just but one of PEDDS’ functions – and PEDDS will be used even if data is not electronically signed / sealed.
The synchronization process involves a "requestor" (the one who wants to be
synchronized) and a "responder" (the one who has the version of a project that
in the end, will update the requestor).
The process starts where the requestor has opened an active project, and creates a synchronization request package. This is essentially nothing more than a zip file of his Manifest. It is a good idea if the requestor has just secured his version of the project before creating the synchronization request package. The resulting package file (*.pkg) may be transmitted to the responder, and is usually small enough to send even by e-mail.
Likewise, the responder should start with a freshly secure project. The responder receives, then opens the request package. PEDDS compares the requestor's Manifest with the local responder's Manifest. All files modified or added (different than the requestor's) are zipped into a response package, along with instructions for PEDDS to delete any files from the requestor's version of the project the responder doesn't have.
The response package is then sent back to the requestor (this is also a .pkg file, but is larger because it may contain many additional or modified files the requestor doesn't have).
The requestor opens the response package and is given a chance to review what is about to take place on his version of the project before continuing. If the requestor continues, files in the response package are added to his project and files the responder didn't have are removed from the requestor's project until both projects (requestor's and responder's) are synchronized (made exactly the same), that is matching the responder's version of the project.
For more information please visit the following links:
PEDDS Synchronization Presentation
PEDDS Synchronization Summary
The county/section data (for counties 1-9) in ProjectID.xml must be corrected to read 01-09.
Correcting ProjectIDReport.xsl or Counties.xml does not correct the data, only the hard copy report. You can use notepad to make the changes.
Single digit county reference
County with correct reference