How would XML export work?

[Spliff]

I have a sub tree with 1100 items, does NOT contain cloned items.

Export to CSV (children rec.) to file some.csv works > 1100 rows.

Problem 1:

Export to XML/OPML (children rec.), to file some.xml, even with just itemtitles and flag, let alone with itemtext or even itemcontent (rtf), produces monster files, I have to manually cancel. Example: stopped after about 40 minutes, over 200,000 times "outline created", while for itemcontent (rtf) not 1100 extra folders will have been created, but less than 300; this latter phenomenon may be caused by the fact that the other 800 items may not have content though, didn't check that.

It seems the special chars I use in the item titles are not at fault; when I export a tiny sub tree containing them, there is no problem. So it's the size of the sub tree, even without content? (Btw, the same problem occurs for ALL xml export "html" formats: none, dynamic outline, html, rss, static outline.)


Problem 2:

I don't want to mix it all up here, but when I export "Docs & Richtext to Folder (children rec.)" instead, the necessary folders / subfolders are created, BUT their names are so much shortened that the result is unusable, has nothing to do with Win 260 or 250 char limit, there would be plenty of "room" to get the folder names correct (haven't checked out the file names yet).

So, currently, I don't get even out just a full sub tree of reasonable length; it's true that with order-preserving search, I wouldn't need to. ;-)



Ad Problem 2:

Would like to know the cause for the terribly shortened folder names.


Ad Problem 1:

Did Compact & Repair. Same result.
Copied the whole sub tree into another db, then export from there. Same result.

Another sub tree, with 12,000 items, exported correctly (seemingly, didn't check the results, just counted them and verified the export here didn't get into an endless loop).

Have visually checked the faulty sub tree again and again, do not see any possible cause for that endless recursion - of course, how could it be otherwise, that's the one I would want to export.

What should I search the (at some time stopped, but then searchable by me) output .xml output file for, in order to "get" to the point of recursion in there, in order to identify the problem character within the output which triggers the recursion? (Has currently, and without any "text" or "content", just titles and flags, 23,000 times "outline created".

Have to say (tried 2 times) that the export from the sub tree in question doesn't contain any title from that sub tree, but while running endlessly, just elements outside of that sub tree (which opens / works totally normally from within the tree otherwise).



Problem 2: Answer pending.

Problem 1: Resolved:

Well, sometimes, I overlook the obvious. Don't have any SEARCH item within the sub tree you want to export! ;-)

[kinook]

Problem 1: That was a nasty little bug. This has been fixed in the latest download to not recursively export search results that have the search item in the results.

Problem 2: Exported filenames are truncated to 50 characters, because Windows is limited to total folder+filename length of 260 characters (even with long paths enabled, most applications don't support them), and especially when exporting a tree structure, it can quickly exceed the max path length. But in the latest download, this is now configurable via reg setting MaxExportFilenameLength, allowing you to more easily shoot yourself in the foot.

[Spliff]

Thank you!

In fact, I had found the same name truncations in the file names of the dedicated XML folders, upon xml export.

In those though, the full title info was / is within the respective title fields of the respective "record" in the xml file, the necessary "connection" info being, in the xml file, the ID number, and, for the html, the respective ID-numbered, specific folder, so there, the truncated info was / is redundant anyway... which was not also the case with RTF export, where the full title info was lost then. So it's a good thing to have made this available for the user. (XML export is preferable wherever possible anyway.)

Little question:
How/where do you store SAVED exports? They are VERY helpful indeed, but whenever I made a mistake, that export clutters the saved exports list, and can NOT be renamed either, since any rename would then store a variant under the new name (which is a good thing indeed), but with no evident way to delete (sic!) the unneeded stored search.

It's just the non-disappearance of stored searches not needed anymore which is the problem, the way of creating renamed variants though is absolutely perfect.


EDIT: Little suggestion:
Since I'm just writing about my (own) filter, it occurs to me that currently, all exports are to FILES, whilst ofen, especially for tiny exports, all I would need would be the CLIPBOARD: would that be possible where it would make sense? (i.e. exports without (sic!) creation of html folders for example, but not only csv)

[kinook]

These are stored in the Windows registry under

HKEY_CURRENT_USER\SOFTWARE\Kinook Software\Ultra Recall\Settings\ExportDlg\Sets

Export is to files only. There isn't much standardization of formats that would be useful for clipboard export, and a lot of work to support it for each export type. If there is a meaningful clipboard format, it is probably available by copying from within UR.

[Spliff]

Thanks, that's been a very good hint for other such things, too, UR writing quite some settings into the registry, and in there, I can now delete unwanted exports.

As for clipboard export, that would have been csv, especially, and in case you may NOT implement my brilliant filter (which the usual haters will obviously defame as irrelevant, as usual, whilst in fact it's the best on the market) - even TB should lick all their 10 fingers about it (or they may simply steal it btw, in order to justify their outrageous pricing):

Thus, in case of possible non-implementation into UR, I'll have to rely again and again on my UR-filter-by-csv-export up to the end of my days; so I now write the csv output to a file on A:, A: not being a 3,5" disk, but a / the last free Softperfect Ramdisk (1gb, I also use it to listen to CD music in very best quality). And no, the filter speed isn't abysmally low then, for my usual projects of between 800 to 2000 items. ;-)