GWP automated idpr does not follows the changes in associated files

Re: GWP automated idpr does not follows the changes in associated files

Sergey Proforov — Thu, 25 Jul 2013 13:15:04 GMT

Many thanks! We will try 'touch' file once a day.

Is there any xsd document for PubConfig.xml to extract all published automated iDPR?

Re: GWP automated idpr does not follows the changes in associated files

Nelson Hobdell — Wed, 24 Jul 2013 04:45:24 GMT

Jerry just 'read my mind', although 12 hours ahead of me.

Sergey, I see no particular reason that the nested reference attachments should be a problem. It should work.

Just ensure that your attachments are set to Live Nesting, and with the appropriate depth etc.

With complexity comes the ability to compromise the system. If a problematic file is added at the Nth level of nesting, would it be difficult to troubleshoot?

So also consider backing up your

monday.dgn

tuesday,.dgn

etc.

* Jerry's command/batch file might also so the backup/renaming for you.

Likewise, always consider backing up production server configuration files. (Pubconfig.xml, ...)

Re: GWP automated idpr does not follows the changes in associated files

Jerry Walter - Bentley — Mon, 22 Jul 2013 17:05:22 GMT

Just 'touch' the main file. You can set up a Windows AT command , and schedule it to run ince a day. GWP should take care of the rest.

Re: GWP automated idpr does not follows the changes in associated files

Sergey Proforov — Mon, 22 Jul 2013 14:22:17 GMT

Nelson, Jerry, thank you for responces.

Of course I mean "references", and of course I would like to do a change request. What should I do for it?

The solution "creating a 'layer' for each of the reference attachments" takes his place, but in this case it's too difficult to publish all references separately (look at the picture for example, this is a most simple case, is other cases we have a hundreds of references).

Left folder is a root for the project, next level of folders is for departments, which takes a part in the project. Next levels may be very complex.

On a third level of the project folder structure we have a master files, which collects all data and makes a big picture.

Master files are not changed often, they are used for printing.

We want to do a more automatic system, and for our case we can assume another solution:

1) Publish a master file as an automated idpr, which includes all other files needed for particular case.

2) Open master file once a day, using Bentley SDK, and resave it (change date for the file)

3) GWP tracks changes in master file by date (as I assume), so all changes in references will be taken into account.

How do you think, is this solutions have chance to live?

Re: GWP automated idpr does not follows the changes in associated files

Jerry Walter - Bentley — Fri, 19 Jul 2013 22:18:46 GMT

As well as Nelson's comments. You may want to consider creating a 'layer' for each of the reference attachments, so that the GWP output mimics the reference attachment schema. This also would have to be done just once, but may give you more flexibility in the usage of those various files.

Re: GWP automated idpr does not follows the changes in associated files

Nelson Hobdell — Fri, 19 Jul 2013 21:23:08 GMT

Hello Sergey,

By 'Associated', I believe that we are intending 'Reference’ files.

Of course, a reference file structure created within MicroStation can be quite complex and possibly replete with missing or otherwise invalid path references. (perhaps the GWP process does not have access or permissions to certain paths, etc). So, accounting for these aspects can be difficult. Nonetheless, we can consider filing a change request for this functionality, but it may come with some limitations (perhaps a nesting depth limitation, a 'what to do when we cannot resolve a reference' timeout limitation, etc.). If you would like a change request in that light, please let us know your desires regarding those scenarios.

As a stop-gap measure, you may run the iDPRcnv.exe commands via a scheduled batch file. This is mentioned within the prepublishing documentation:

docs.bentley.com/.../GUID-105B1F4D-99D6-4961-96E6-4EB017A76208.html

Consider also that perhaps a scenario without the use of the master/reference relationship may be suitable in your case, if you do not rely on functionality specific to the reference attachment.

i.e. As “all roads lead to” the same iDPR file ultimately, could the reference files be added directly as Automated iDPR Input files, thus making use of the inherent change tracking?