Jason Miller

So it's not exactly indexing in this case, that happens when doing an upgrade and notes are migrated to a updated DB - our normalization process (which just cleans up the note structure behind the scenes) is doing this, however the note needs to be downloaded and then the process run (when you switch notes) for it to finally kick in (which can appear just as slow as indexing - depending on the normal of notes, note size etc. Does this mean it is starting to behave correctly for you (after "indexing" takes place) or are the tables still a problem?

If you have the new table UI options (for example when you are in a table dots appear about columns on top or rows on the left, and/or you see a button that gets you a floating menu with options for background color and such) then you are in the new tables - and once you move the table columns they should stay where you put them. If you don't see the new table features, then the system is getting confused. When I adjust the column width on the previous ENEX file you shared they stay when I switch notes (note helpful for you at the moment probably) This the note you are currently working

No when you adjust them, they should say adjusted - if you right click inside a table and go down the "table" option in the menu that appears is there an update table option?

Ok, so the new fixed width feature of the new tables messed up the formatting (column width) requiring re-adjustment - unfortunately I don't a quick solution for that - though once manually adjusted again, they will stay that way - sorry

I think I am a big confused, the tables when I load the ENEX file don't seemed messed up (attaching a screen shot) - I am not paying attention to the right thing? (or if open a problem note, leave it and return does it get fixed or more messed up?

Filed a new bug for this

By Design, Code Blocks where breaking tables

We put in logic to help prevent this, obviously you have tables that aren't being handled correctly - can you share such a note so Dev can take a look at it and make our table protection logic better?

Not sure what I can hep with then. Do you have a note(s) that can be shared that show the broken behavior, so I can take the info to Dev?

Is this a nested table? (and obviously something is getting through our protect old tables, logic) do you happen to have a problem note you can share so our dev folks can take a look at what is going on?

We have an issue open tracking this - unsure about an ETA for the fix

This is by design, paste and match style will keep the hyperlink

Yes, not sure if that causes you problems in the short term (the note is on my list to sanity check (again) as 6.8 gets closer to going out. To Confirm we didn't break it again.

Yes, a known bug and has been marked to be fixed sooner rather than later, however I don't have an ETA yet.

Sorry for the inconvenience - this is known problem

Thanks for the report, I will have folks research this problem more

:-( thanks for the report, looking into it

So there is a fix for this (tested by me being able to via the note like in your example) the fix won't make the 6.7 Release due to additional testing going on, it will be in 6.8

Thanks for sending the ENEX

Created a new bug for this (including the info you messaged with me)

Technically this isn't for bug reporting and tracking, it is a user forum for discussion and comments about our betas and new features. I shared your info with other Mac folks who work more with syncing issue than I do for better feedback on the issue you are encountering with syncing on a busy network. Since the network is busy, conflicts can happen, however updates are being made to the sync engine to help with this.

That is something in the note that is causing a problem with updates to the edit - is this a note that is safe to share with our developers so they can see what is going on?

I think I found it

Can you point me to the original post you made on the issue you ran into?

Sorry that is the current design with the new tables