File/Folder Names Truncated on Export from UR

[maynard]

I exported a node recursively from a UR tree that has the following sub-folders in UR:
TPE Domain A - Making Subject Matter Comprehensible to Students
TPE Domain C - Engaging and Supporting Students in Learning
TPE Domain D - Planning Instruction and Designing Learning Experiences for Students
TPE Domain E - Creating and Maintaining Effective Environments for Student Learning
TPE Domain F - Developing as a Professional Educator

Upon export, the resulting folder names on disk are all truncated to 51 chars long:
TPE Domain A - Making Subject Matter Comprehensibl
TPE Domain C - Engaging and Supporting Students in
TPE Domain D - Planning Instruction and Designing
TPE Domain E - Creating and Maintaining Effective
TPE Domain F - Developing as a Professional Educat

Also, this 51 char limit seems to apply to the names of items at each level of the exported hierarchy. Examples from filesystem after export:
-----------------------Folder (51 char limit)---------------------------File (51 char limit)---------------------------
a) TPE Domain A - Making Subject Matter Comprehensibl\TED624 - Physics - Reflection and Refraction of Li.pdf
b) TPE Domain A - Making Subject Matter Comprehensibl\TED611 - Physics - Speed - Lesson Plan.pdf
c) TPE Domain B - Assessing Student Learning\TED625A - Force of Friction - Lesson Plan.pdf
d) TPE Domain B - Assessing Student Learning\TED630 - Earth Science - Unit6 - Geologic Time Sca.pdf

Results:
a) Folder and file names (each GT 51) get truncated
b) Folder name (GT 51) gets trunctated but filename (LT 51) does not
c) Folder name (LT 51) does not get truncated but filename (GT 51) does.
d) Folder name and file name are each LT 51. Neither gets truncated. (this is the only case that is correct)
Note: In all file cases, the file extension does not get truncated but is properly appended to the truncated filename.

I moved the database file into a folder with a very short path (E:\Temp) and exported to the same folder to see if the pathname of the orginal source folder was too long. Still got the same results.

I tried compacting and repairing the database and got the following error:
Error repairing database: no such table: ttForm

I then tried compacting first and then repairing in a separate step. The compact ran fine but the repair generated the same error.

I then created a new database from a custom UR template.urd I've been using for awhile, copied the node I was trying to export from the 1st UR DB to the new DB and exported with the same truncated results. I then did a repair/compact on the new database which failed with the same error as above.

I then renamed template.urd to template.urd.bak and created another new DB using UR defaults. I immediately did a repair/compact on that DB and both ran fine. I then copied the node data from the original DB to the new default DB, did a successful repair/compact and exported again. No luck... got exactly the same truncated results.

Also, I received the following errors after working with the database pretty heavily over the course of the evening (a lot of copy, move, delete operations):
Selecting tree item - Error loading item(s): out of memory
Expanding tree item - Error expanding tree: out of memory

Help.

TIA
maynard

---------------------------
Environment:
UR 3.1.1
Windows XP SP2

[kevina]

The 50 character truncation that occurs is by design as a way to minimize the impact of the 260 max path character limit imposed by Windows (technically you can create longer paths and UR could do that, but then the exported files would not be accessible by most other programs - including Windows Explorer and Microsoft Office)...

Since there technically is "no way" that the ttForm error could occur when Repairing a database, we would be interested in having you send the smallest reproducing .urd file (zipped) to support@kinook.com for our evaluation (obviously it is occurring so there must be a way)...

The error loading items (out of memory) issue has been reported by one other user but we have not been successful in reproducing the error - it should never cause data loss. Any identified reproducible sequence of actions would be most helpful along with any other info that be provided...

[maynard]

It figures... I can't reproduce the ttForm error now. For whatever reason, I was able to repair/compact all my urd files. Must be the phase of the moon my computer was in at the time.

Re. the out of memory condition. I will trace a sequence of events and get back to you. I'm also seeing a lot of access violations in conjunction with that. I'll document what I can.

Thanks
Mark