Going from 2016 to 2017

[jessica.miller]

We are using 2017 for the purpose of data referencing corridors.  We are having major time eater issues with our projects as of here recently.  

What we are experiencing is 15-45mins. opening times for files.  We can save the file to our server after opening.  The same file then only takes 0-5 mins to re-open.  We work all day just fine.  When we come in the next day we start back at 15-45mins. for opening.  It's like Ground Hog Day...  Every time we think we found a solution, we are sadly disappointed the next day.  

We have done extensive research & testing on the issue including all forms of data reduction, corruption of files on working, data, & support types including replacing the .dbx file (Autodesk solution); none of which have resolved the issue.  We are currently recreating these files from scratch in 2017, as they were started in 2016.  They continued to be worked on in 2017 as the design team migrated versions.  I'll report back with results.

I'm just wondering if anyone else has had a the same issue related to this situation.  I would be nice to know variable as to what's causing the open delay, whether it be software, hardware, or technical.  Once we pin point the cause, we can move forward & determine a fix for it.  Whatever the issue may be has cost us much frustration & many hours in production.       

[jessica.miller]

We are using 2017 for the purpose of data referencing corridors.  We are having major time eater issues with our projects as of here recently.  

What we are experiencing is 15-45mins. opening times for files.  We can save the file to our server after opening.  The same file then only takes 0-5 mins to re-open.  We work all day just fine.  When we come in the next day we start back at 15-45mins. for opening.  It's like Ground Hog Day...  Every time we think we found a solution, we are sadly disappointed the next day.  

We have done extensive research & testing on the issue including all forms of data reduction, corruption of files on working, data, & support types including replacing the .dbx file (Autodesk solution); none of which have resolved the issue.  We are currently recreating these files from scratch in 2017, as they were started in 2016.  They continued to be worked on in 2017 as the design team migrated versions.  I'll report back with results.

I'm just wondering if anyone else has had a the same issue related to this situation.  I would be nice to know variable as to what's causing the open delay, whether it be software, hardware, or technical.  Once we pin point the cause, we can move forward & determine a fix for it.  Whatever the issue may be has cost us much frustration & many hours in production.       

[wfberry]

Make sure that you have converted (updated) all referenced files to version 2017 as well.

Bill

[wfberry]

Make sure that you have converted (updated) all referenced files to version 2017 as well.

Bill

[jessica.miller]

Reference files have been updated as well.

[jessica.miller]

Reference files have been updated as well.

[Anonymous]

you probably need to run a hotfix that was issued to speed up loading times... can't seem to find it online though, it was called civil3d performance hotfix.  essentially it replaces the aeccnetwork.dbx file with a reworked file to speed up civil 3d.

[Anonymous]

you probably need to run a hotfix that was issued to speed up loading times... can't seem to find it online though, it was called civil3d performance hotfix.  essentially it replaces the aeccnetwork.dbx file with a reworked file to speed up civil 3d.

[jessica.miller]

We have run that.  The aeccnetwork.dbx file is the .dbx file referred above.

[jessica.miller]

We have run that.  The aeccnetwork.dbx file is the .dbx file referred above.

[jessica.miller]

I'm reporting back on the start from scratch in Civil3D2017 recreation of files originally created in Civil3D2016:

We've only done this with one file, but it seems to work.  I'll try more & continue to report back.

As we have 15-20 problem dwgs with this conversion issue, that's a good week's worth of work.  We have a deadline in two weeks, so that won't happen. (This is the 3rd deadline the conversion error has afftected costing our company time & money; unacceptable.)  We are thinking to write a script & deploy it overnight, so that we can work at reasonable operating speeds during regular business hours. 

[jessica.miller]

I'm reporting back on the start from scratch in Civil3D2017 recreation of files originally created in Civil3D2016:

We've only done this with one file, but it seems to work.  I'll try more & continue to report back.

As we have 15-20 problem dwgs with this conversion issue, that's a good week's worth of work.  We have a deadline in two weeks, so that won't happen. (This is the 3rd deadline the conversion error has afftected costing our company time & money; unacceptable.)  We are thinking to write a script & deploy it overnight, so that we can work at reasonable operating speeds during regular business hours. 

[Cadguru42]

---

@jessica.miller wrote:

I'm reporting back on the start from scratch in Civil3D2017 recreation of files originally created in Civil3D2016:

We've only done this with one file, but it seems to work.  I'll try more & continue to report back.

As we have 15-20 problem dwgs with this conversion issue, that's a good week's worth of work.  We have a deadline in two weeks, so that won't happen. (This is the 3rd deadline the conversion error has afftected costing our company time & money; unacceptable.)  We are thinking to write a script & deploy it overnight, so that we can work at reasonable operating speeds during regular business hours. 

---

This is one of the reasons that I highly recommend never upgrading software versions in the middle of a project. If you start a job in one version keep it in that version. 

One of the issues Autodesk has is that corridors aren't very stable when they become complex. Ever since C3D 2012 I've noticed that corridors can become corrupt for no reason and that even Autodesk itself can't explain what's going on. Add in the fact that the C3D object model changed in 2017 and I can see how issues could arise by making a 2016 drawing into a 2017 drawing. 

[Cadguru42]

---

@jessica.miller wrote:

I'm reporting back on the start from scratch in Civil3D2017 recreation of files originally created in Civil3D2016:

We've only done this with one file, but it seems to work.  I'll try more & continue to report back.

As we have 15-20 problem dwgs with this conversion issue, that's a good week's worth of work.  We have a deadline in two weeks, so that won't happen. (This is the 3rd deadline the conversion error has afftected costing our company time & money; unacceptable.)  We are thinking to write a script & deploy it overnight, so that we can work at reasonable operating speeds during regular business hours. 

---

This is one of the reasons that I highly recommend never upgrading software versions in the middle of a project. If you start a job in one version keep it in that version. 

One of the issues Autodesk has is that corridors aren't very stable when they become complex. Ever since C3D 2012 I've noticed that corridors can become corrupt for no reason and that even Autodesk itself can't explain what's going on. Add in the fact that the C3D object model changed in 2017 and I can see how issues could arise by making a 2016 drawing into a 2017 drawing. 

[rkmcswain]

johngordon6189 wrote:

you probably need to run a hotfix that was issued to speed up loading times... can't seem to find it online though, it was called civil3d performance hotfix.  essentially it replaces the aeccnetwork.dbx file with a reworked file to speed up civil 3d.

It should probably be noted here that SP1 for Civil 3D 2017 and later includes this "fix", so downloading and replacing this .dbx file is not necessary if your 2017 is fully patched otherwise.

Also, to clarify - This "fix" does not "speed up" Civil 3D. The "fix" (replacement .dbx file) - simply keeps Civil 3D from introducing data bloat into the .DWG file when saved, which is what is happening starting in version 2014 by default. The replacement .dbx file must be installed, and the bloated data file must be opened (it will still take a LONG time), and then SAVED. At this point this particular .DWG file is "clean", although any other .DWG files used as references (Xref, or Data shortcut) must also be opened and saved on a machine with this fix. If a non-patched version of Civil 3D is used to open and save the .DWG, the bloat will return.

[rkmcswain]

johngordon6189 wrote:

you probably need to run a hotfix that was issued to speed up loading times... can't seem to find it online though, it was called civil3d performance hotfix.  essentially it replaces the aeccnetwork.dbx file with a reworked file to speed up civil 3d.

It should probably be noted here that SP1 for Civil 3D 2017 and later includes this "fix", so downloading and replacing this .dbx file is not necessary if your 2017 is fully patched otherwise.

Also, to clarify - This "fix" does not "speed up" Civil 3D. The "fix" (replacement .dbx file) - simply keeps Civil 3D from introducing data bloat into the .DWG file when saved, which is what is happening starting in version 2014 by default. The replacement .dbx file must be installed, and the bloated data file must be opened (it will still take a LONG time), and then SAVED. At this point this particular .DWG file is "clean", although any other .DWG files used as references (Xref, or Data shortcut) must also be opened and saved on a machine with this fix. If a non-patched version of Civil 3D is used to open and save the .DWG, the bloat will return.

[jessica.miller]

We've ruled out drawing bloat.  

In hind sight I see the validity in your point of not moving project from one version to the next.  The project in discussion here I would consider having complex corridors, as it is a multi-lane highway interchange project with as many as 15 alignments.  Like I said we moved it because of the opportunity to data ref. corridors.  Again in hind sight, we've since moved away from using corridors in cross sections & are now using more surfaces.  Corridors work fine for our small county road projects & one alignment projects.  They to date still do not offer what we need for our large highway designs.  They do get the bulk of our surfaces for these more complex projects, but inevitably we are grading & manipulating surfaces at headers & gores or any special drainage.  

[jessica.miller]

We've ruled out drawing bloat.  

In hind sight I see the validity in your point of not moving project from one version to the next.  The project in discussion here I would consider having complex corridors, as it is a multi-lane highway interchange project with as many as 15 alignments.  Like I said we moved it because of the opportunity to data ref. corridors.  Again in hind sight, we've since moved away from using corridors in cross sections & are now using more surfaces.  Corridors work fine for our small county road projects & one alignment projects.  They to date still do not offer what we need for our large highway designs.  They do get the bulk of our surfaces for these more complex projects, but inevitably we are grading & manipulating surfaces at headers & gores or any special drainage.  

[ITandCADguy]

By any chance do your computers have any Junctions being used.  By that, I mean the folder is on a different drive, but there is a Pointer on a different drive that makes the OS thinks it's there instead.

Microsoft's definition:

• A junction (also called a soft link) differs from a hard link in that the storage objects it references are separate directories, and a junction can link directories located on different local volumes on the same computer.

For example, C3D Projects is really located on D:/ drive, but a Junction makes it look like it's on C:/ drive.

I ran into this problem when I first installed Civil 3D 2017.  Opening 2017 files with xrefs or data shortcuts worked just fine, but if an XREF or DREF was in 2016 format it took forever to load.  Updating all references to the 2017 format did not solve the issue.

It was identified as a bug and reported to development, but I don't know if it ever got fixed via a service pack.

[ITandCADguy]

By any chance do your computers have any Junctions being used.  By that, I mean the folder is on a different drive, but there is a Pointer on a different drive that makes the OS thinks it's there instead.

Microsoft's definition:

• A junction (also called a soft link) differs from a hard link in that the storage objects it references are separate directories, and a junction can link directories located on different local volumes on the same computer.

For example, C3D Projects is really located on D:/ drive, but a Junction makes it look like it's on C:/ drive.

I ran into this problem when I first installed Civil 3D 2017.  Opening 2017 files with xrefs or data shortcuts worked just fine, but if an XREF or DREF was in 2016 format it took forever to load.  Updating all references to the 2017 format did not solve the issue.

It was identified as a bug and reported to development, but I don't know if it ever got fixed via a service pack.

[jessica.miller]

Per my IT team we use a technology called DFS...

[jessica.miller]

Per my IT team we use a technology called DFS...

[jessica.miller · Accepted solution]

So to report back on this...

We are no longer using corridor data references in our production cross section files.  

The ability to reference corridors drove our justification for moving to 2017, leading to an epic fail on our part.  Data shortcuts for corridors need to be repaired almost every time we open the file.  This takes an enormous amount of time away from production' anywhere from 15-45 mins. per dwg.  This is extremely inefficient for what we do.  Unfortunately, I have no explanation for why all other data shortcuts remain in tact.  

We are now using surface references, instead of corridors, for graphics in our production cross section files.  This does not fix the data connection issue.  It merely avoids it.  It does however work for what we need.  

[jessica.miller · Accepted solution]

So to report back on this...

We are no longer using corridor data references in our production cross section files.  

The ability to reference corridors drove our justification for moving to 2017, leading to an epic fail on our part.  Data shortcuts for corridors need to be repaired almost every time we open the file.  This takes an enormous amount of time away from production' anywhere from 15-45 mins. per dwg.  This is extremely inefficient for what we do.  Unfortunately, I have no explanation for why all other data shortcuts remain in tact.  

We are now using surface references, instead of corridors, for graphics in our production cross section files.  This does not fix the data connection issue.  It merely avoids it.  It does however work for what we need.