curious behavior pack&go

[andrea.boerio]

I happened (but success, or never before) to open a set (with two loaded parts) and want to pack & go into a new folder that still does not exist.

set a default prefix for all new files (a set and two parts, then), selected the new destination folder, confirmed everything and given the "save". all normal here.

I go to check in the folder and there are all three files, each with the modified name (Add the prefix), as I expected.

I open the new set, and this points to the original files. . Absurd. created everything, but did not update the links within the new set, which then turns out a copy of the original, only with different name.

I have done the test several times, with the same together, and sometimes does what I expect (i.e. new together pointing to new files), and sometimes not.
I know it sounds like a blasphemy, but I can't identify the behavior that determines the failure of the procedure.

What I find absurd, is that in the pack and go, even if you want, there is no option that allows you to create new files by untieting them, right? If I select from the list the axieme and its components, the copy of the axieme that I go to create should point to the new components. and if you had not selected the components, perhaps for my mistake, you should not create them, copies of the components, and not create them "but not use them".

At this point I tried to repeat everything by registering the thing via rx, to send the data to the assistance, and there is no way to replicate the problem. in practice to bright cameras known a wait time slightly greater after the moment of the rescue, but when I open then the created axieme is all perfect... stuff to get teased by assistance...

 

[Mike1967]

I happened (but success, or never before) to open a set (with two loaded parts) and want to pack & go into a new folder that still does not exist.

set a default prefix for all new files (a set and two parts, then), selected the new destination folder, confirmed everything and given the "save". all normal here.

I go to check in the folder and there are all three files, each with the modified name (Add the prefix), as I expected.

I open the new set, and this points to the original files. . Absurd. created everything, but did not update the links within the new set, which then turns out a copy of the original, only with different name.

I have done the test several times, with the same together, and sometimes does what I expect (i.e. new together pointing to new files), and sometimes not.
I know it sounds like a blasphemy, but I can't identify the behavior that determines the failure of the procedure.

What I find absurd, is that in the pack and go, even if you want, there is no option that allows you to create new files by untieting them, right? If I select from the list the axieme and its components, the copy of the axieme that I go to create should point to the new components. and if you had not selected the components, perhaps for my mistake, you should not create them, copies of the components, and not create them "but not use them".

At this point I tried to repeat everything by registering the thing via rx, to send the data to the assistance, and there is no way to replicate the problem. in practice to bright cameras known a wait time slightly greater after the moment of the rescue, but when I open then the created axieme is all perfect... stuff to get teased by assistance...

try to select "flat view" instead of "sold magazine". (top left in p&g.)
Let me know.
Remember that it is important that "packed" files do not have the same names. (You did well to use the prefix)

 

[andrea.boerio]

try to select "flat view" instead of "sold magazine". (top left in p&g.)
Let me know.
Remember that it is important that "packed" files do not have the same names. (You did well to use the prefix)

Nothing. It creates everything, but the new together points to the old parts.
on the other hand it works...
on the station of a colleague of mine before did not give problems (the same file, same operation)
on my station, another set didn't give a problem.
reading parts or just writing, whether it is, do not seem to make a difference.
:redface:

p.
for the speech "news" I have long been making a battle, in the company, since for the moment we do not have a pdm. I also made a macro for the regular verification of the names present in the directors of work, that I turn daily (with regular surprises)

 

[Mike1967]

Nothing. It creates everything, but the new together points to the old parts.
on the other hand it works...
on the station of a colleague of mine before did not give problems (the same file, same operation)
on my station, another set didn't give a problem.
reading parts or just writing, whether it is, do not seem to make a difference.
:redface:

p.
for the speech "news" I have long been making a battle, in the company, since for the moment we do not have a pdm. I also made a macro for the regular verification of the names present in the directors of work, that I turn daily (with regular surprises)

I would not say, but it may be that this problem and the problem you described in the other
threads are connected.

 

[andrea.boerio]

I would not say, but it may be that this problem and the problem you described in the other
threads are connected.

boh, on that station actually lacks a menu option, so as soon as possible I will ask you to "come out".

on my station there is nothing missing, only that "sometimes" the result of the operation described is not expected, especially not understanding what my possible behavior is generating a result rather than the other (I also begin to doubt the network).

For example, five minutes ago everything worked.

the only aspect that seems to me recurring is that if instead of saving the copies directly in the destination folder saves them in a zip, and then I extract the zip, then the links are in place, all within that folder (I am touching me.. . ).

for safety I will ask everyone to always check the operation for some time. If I find out something, I will.
Thank you.

 

[SolidUser]

boh, on that station actually lacks a menu option, so as soon as possible I will ask you to "come out".

on my station there is nothing missing, only that "sometimes" the result of the operation described is not expected, especially not understanding what my possible behavior is generating a result rather than the other (I also begin to doubt the network).

For example, five minutes ago everything worked.

the only aspect that seems to me recurring is that if instead of saving the copies directly in the destination folder saves them in a zip, and then I extract the zip, then the links are in place, all within that folder (I am touching me.. . ).

for safety I will ask everyone to always check the operation for some time. If I find out something, I will.
Thank you.

to come to the end it is necessary to go for exclusion.
since the problem does not repeat on other machines, you should start by cleaning the pc through the sw tool, and reset the solidworks logs.
at this point you begin to exclude the network and that is to run the pack&go in local.
If the problem does not recur, then it could be a network problem very likely.
perhaps mappings of different paths or files that remain 'appesi'.
However it is always good standard to perform tests in cleaning situations and without external interference.