UR's Export Is Unreliable

[schferk]

After heavy editing - I didn't want to do a tort - I'm positive now:

UR ist faulty in its csv export. It does mix up item titles, be they direct neighbours or in the vicinity one to the other. The exported item list is NOT necessarily in the order of the items in the original tree, and thus, copying this list into an AO tree (or any other prog) and then doing a one-by-one copy and paste operation between the two progs will fill up a posssibly FALSE tree, taken not from the original tree, but from the export list (original content of item 200 becoming the content of item 202, and vice versa, e.g.).

All my programming efforts here are not at fault, neither is the Windows clipboard function, nor is AO or any of my editors : manual comparing of the items, one by one, of the raw, un-processed list exported by UR shows, here and there, or even many, discrepancies between the UR tree and the exported list.

The thread's title is correct then, and for the time being, I cannot see that it's some special chars in those title lines that trigger the mixing up.

Thus, intermediate solution, selecting the original tree, copying it into a second list, and let Beyond Compare compare for discrepancies. Then, wherever necessary, manual reordering of misplaced items in UR's faulty export list, needed to be processed by the script for the tab info.

Thus, people using UR's export (and perhaps also print???) functions for serious business, should check UR's output twice.

But now, let's have a good laugh together :

If you copy the tree directly from UR's original tree - which doesn't function well / always at first try... -, you can paste that clipboard content directly into AO or whatever, with all the leading tabs in the right places altogether. So, my formidable detour by UR's faulty export tree, then being (correctly) processed by my TSE script : 100 p.c. unnecessary.

All this unpaid extra work just for discovering that UR's Export Is Unreliable. Frightening.

But anything can be topped, then :

http://www.welt.de/vermischtes/article13684884/Geldscheine-halbieren-Wert-um-25-Prozent-steigern.html

[schferk]

RTF export is unreliable as well.

I'm positive now on this second bug but which occurs rarely, compared to the one described above.

We know that UR exports only those parts of the tree that are both expanded and selected; I prefer it otherwise but see the point in this way to do it.

But then, here and then, UR SKIPS some such and-expanded-and-selected parts of the tree, so that your export isn't sure to contain all you want to export (and this when you've got a normal, continuous selection, not as a possible side effect of discontinuous selection by control-mous-clicks, and not for possible monster tree exports, but some dozens of items to be exported will suffice - again, it's quite rare, but I'm positive).

If you export in .rtf format, be it for further processing / publishing out of MS Word or out of a dtp prog (InDesign or whatever), you risk here to leave out whole chapters, without ever knowing it except after publication when third parties speak of inconsistencies in your product.

Thus, anybody wishing to export UR data is well advised to also do it by external macro going back and forth, copying and pasting by clipboard, then to compare the results.

(I'm speaking here of precisely this export command: File - Export - Text items to a rtf doc - include item titles/insert page breaks/include item notes - Target file and Enter. And since there's a lot of confusion with the following command, "Item notes to a rtf doc", let me add that it's not that those skipped items only contained pics, and thus did not contain text, as one might think by (too) carefully reading those badly chosen/distinguished command denominations.)

[Nobodo]

I am having the same problem as OP on exporting.

I am exporting to HTML.

It looks like it completely ignores the way items have been moved around in the Data Explorer, and instead builds toc.html in the order items were created.

The images are of a hoisted section in UR itself, and the resulting toc.html on an html export I just did a few minutes ago.

[kinook]

It does look like the sort order is different, but I'm not seeing any missing info in my tests. Please ZIP and send a .urd file that demonstrates the problem. Thanks.
http://www.kinook.com/Forum/showthread.php?t=3038

[Nobodo]

I am not seeing any missing data, just incorrect sort order.

The sort order is important to me because it is a list of programming projects on my todo list, sorted in the order I am working on them. When I export them for business analysts to view, they think I'm working on things that I probably won't touch for weeks.

Thanks,
Mark.

[Nobodo]

More info -- it appears that the export sorts items as they were originally created. I change the order of items daily as priorities change, so it would be great if the export honored the changes.

Thanks,
Mark.

[kinook]

In the latest download, XML/HTML export have been fixed to sort in tree order.

[Nobodo]

In the latest download, XML/HTML export have been fixed to sort in tree order.

I'm using 4.2b, and just did a new version check and it reports to be the latest.
Is there something special I have to do to get it to export in tree order?

[$bill]

see
http://kinook.com/Forum/showthread.php?t=4932

[Nobodo]

In 4.2b on Win7 Ultimate 64bit I just did this as a test:


Created a new database
Added 4 child text items to the default 'Notes' item, and named them 1, 2, 3, 4 in the order of creation.
Used Ctrl-Shft-Up and Ctrl-Shft-Down to change the order of the text items.
Exported as HTML, and noted that it did not export in the Data Explorer order, but instead in creation order.
Closed UR entirely, and then reopened the database (to ensure it wasn't some change done in memory not on disk).
Exported as HTML again, same problem.


I also notice that if you select the root 'My Data' node and try to export as HTML from there, the export just hangs on the below screen. I tried several times with different databases, even a blank new database, same results. If I choose a subitem of 'My Data' and export from there, the export works with the exception items are out of order.


Attempts to export as HTML (with subitems) from the root 'My Data' item hangs on this, and you have to click the 'Cancel' button.

[Nobodo]

see
http://kinook.com/Forum/showthread.php?t=4932

Oh, ok. I always check for updates by doing 'Help' - 'Check for Updates'. With the November 4.2b, 'Check for Updates' reports that you have the latest version.

I manually downloaded the update from the above linked thread.

I confirm that the sorting on export to HTML issue is now corrected. Great, that is wonderful!

However, the problem I reported a few minutes ago of exporting to HTML from the root node with 'Export child items' selected is still present.

Personally, I always export from a child node. However, some people might try exporting from the root node.

To recreate this problem:

Select the root 'My Data' node in a new database.
Export as HTML, with 'Export child items' selected.
The export will hang as described in my last posting.
NOTE: If you do this with an existing database (not a new one) it will also hang, but not necessarily on the 'Search' item.


Thanks for the help!
Mark.

[kinook]

Modify the My Data -> Templates -> Search item so that it doesn't match any items, otherwise you'll end up with a recursive export. Or just select the top-level items to export (excluding Templates, Recycle Bin, etc.).