dynamic block with attributes using lookuptables to populate values invalid

[spartan_vng]

Ok here it goes.  I am using autocad 2017 electric. I currently using dynamic blocks for din rail, Panduit and lamacoids that use lookup table to provide information on length , colour  part number etc. everything has been working awesome. you can use dataextraction to build custom reports ( cut schedules , bom etc) or use default ae report tool to do the something similar. You can copy  and paste.or use ae insert command no problem.

My problem is that the drawing is saved to acad 2010 and when some else opens and saves as anything less than 2010 it breaks all my attributes that use lookup table for info. All my values  show ########...... invalid data.  

I know dynamic blocks were introduced in 2007?  so I understand why the attributes are broken  but just curious to know if there is any easy fix other than replacing all blocks.

Short of doing a recovery backup of the file is there a way to "fix" the block. Redefining the block does not work  or going to block editor and re-establishing the link does not work either. 

Block replace script would work If I can target specific attributes that need to change as I need to be able to avoid attributes that show values of ######.

thanks in advanced

[Libbya]

You might be able to pull up your recovery backup and use qselect to select all iterations of that block and copy/paste them into the drawing where the fields have gone dead.  

[spartan_vng]

Hey Libbya

May work if the drawing hasn't changed, but the problem I see there is that let say after I save my drawing someone else opens it a week later makes the  revisions required and saves accidentally to <2010. When I go open a week/month later blocks are broken. I would like to be able to keep mods to the drawing if possible as it would be painful to go back and find out what revisions were required. Ideally re-establishing the broken link in block editor and redefining the block would be the ideal solution  imo. I guess some one from autodesk need to chime in on this

The problem is that someone may not know they are saving less than 2010 unless to they go and open the drawing and only its when the drawing is opened again that the broken blocks are discovered. There is a warning prompt to tell you are saving to incompatible version but sometime the fingers hit enter automatically.

[Libbya]

I do not believe there is an easier solution than what I mentioned.  However, if you post the block with broken links and I will experiment a little.  

[spartan_vng]

sounds good...thanks for taking the time

please find din rail , Panduit and lamacoid attached

[spartan_vng]

Broken Panduit block attached and broken drawing with lamacoids dinrail and Panduit broken links

[spartan_vng]

Libbya,

FYI.. just realize the attached Panduit block in my first post with attachment is the latest version. The ones in my second post with attachment is an older version  but this should not be the reason why the blocks are breaking or not redefining properly.

[Libbya · Accepted solution]

This is still a PITA, but it will globally fix just the attributes with busted fields without resetting the block to its base state.  You can go into the file with the busted fields and open the block in block editor.  Then copyclip the attribute(s) with the broken fields and then delete it.  Save the block and exit block editor.  Open the block back up in block editor.  Paste the attribute(s) back in place.  Make them visible in the appropriate visibility states and add them to whatever actions moved/rotated them.  Save and exit block editor.  Run ATTSYNC on the block.  The links will work again.  

FYI, you can avoid the 'Custom' state in the lookups by making sure that the as-drawn input parameter values match a row on the table.  

[spartan_vng]

Yup PITA . Haven't tried it yet but after reading your comments sounds like a reasonable fix to me.

as far as the custom thing, I thought long and hard about it. I wanted the user to insert the block and validate it by making the appropriate selections versus just dropping it in and leaving as default. If the designer didn't make the appropriate selection it would show up as custom on the report of some sort so its easy to find.

I'm still on the fence about how to use the "custom" state appropriately for our purposes here.

Thx

[Libbya]

Right on.  Usually the 'custom' state pops up as an issue, but there's nothing wrong with it if it is useful.  You can change the custom name if you want it to say something else, in this case perhaps "Unselected" or somesuch.  Let me know if you have any issues getting the fields linked again.  

[MMcCall402]

Curious ... in the initial post it was mentioned that a redefining of the block didn't fix the problem. Was ATTSYNC run after the block was redefined?

[spartan_vng]

Yes sorry to mention that in my first post attsync did not work after you try and redefine the block. I haven't tried libbya's  redefine work around yet.

I tell ya replacing 100's of blocks is not my idea of fun especially when your trying to finish a package to send out at the 11th hour.

What really irks me is that people break it and just leave it, knowingly they have broken it. At least make and attempt fix and replace it or tell someone what is happening or get the backup from IT.. I you can't fix it or know how....ask for help from the gurus on the forum. This problem was happening on and off over a couple of months. Finally got fed up and sat down with the person to trace their steps to see where the issue was. It took me about 30min to figure they were saving to a lower fricken rev....kill me now lol

sorry had to pop some steam off!

[Libbya]

Redefining will not work in this case because redefining does not change/reset attribute values of attributes that exist in the redefined version of the block.  The same is true for attsync.  It will not update the broken fields because the attributes already exist in the current form. 

The reason that my workaround will work is because it deletes the attribute, then adds it back.  At that point, attsync WILL update to the field links within the block editor because the attribute definition is 'new'.