Lone Wolf Development Forums - Cause of "Parameter is not Valid" error during import?

Lone Wolf Development Forums (http://forums.wolflair.com/index.php)

- Realm Works Discussion (http://forums.wolflair.com/forumdisplay.php?f=67)

- - Cause of "Parameter is not Valid" error during import? (http://forums.wolflair.com/showthread.php?t=64399)

Cause of "Parameter is not Valid" error during import?

I know, I know, me and my import issues...

Just when I figured I was over import hassles, I'm seeing another oddity.

I'm getting "Parameter is not valid" when performing an import (different file than what I was previously dealing with).

Verified it has nothing but a single Mechanics Reference Source article in the import file.

Note: the import appears to have actually succeeded, it just crashed after the import was complete.

Importing multiple articles causes this error and doesn't succeed in the import (it crashes).

Unchecking the preserve ownership flag allows the import to succeed but also duplicates categories (which I suppose is expected).

I'm working on the assumption there's an article in there somewhere triggering the error.

The only way I can think to find this is to try importing a single article at a time until I find the offender.

I swore I wasn't going to dive into the XML of the export files, but it turns out that was the best way to analyze what has been going on.

I found several errant user categories and tags that have been causing intermittent problems. By beautifying and then reading the XML, I've been able to find and purge them.

I think they're leftovers from when I was initially experimenting with imports and exports using the 3 free realms, and I'd thought I'd started clean when creating my base realm but apparently not.

Rather than have to start from scratch, I'm investigating the data to see how I can clean it up in a more targeted way.

Progress is slow and steady.

Wow great ! Imagine we would do an export, run a "fix-it" tool over it resolving common errors like left over categories, the xml version, or the (whatever it is) issue with imports of a realm that has been previously imported.

Quote:

Originally Posted by Acenoid (Post 289025)

<drools enviously/>

That would be really helpful :)

Since I use SlickEdit, I've associated the rwexport and rwstructure file extensions with the XML language definition. That allows me to open the files and beautify them, rather than trying to parse large walls of text.

In the file, it seems built-in categories, domains and tags have a global_uuid attribute on the xml element, while user created ones use original_uuid instead. Also, built in categories, tags and article/topic sections have a "_global" suffix to their element tags, while user created objects just use the base object type as their element name.

Here's a built-in category:

Code:

        <category_global category_id="Category_25" 

                         name="General Article"

                         global_uuid="6C00287B-91C6-5D3A-00D0-6A935C3C6BA9">

            <partition_global partition_id="Partition_72" 

                              name="Overview"

                              global_uuid="A800287B-91C6-5D3A-00D0-6A935C3C6BA9"/>

        </category_global>

...and a user-defined one:

Code:

        <category category_id="Category_80" 

                  name="Malady/Affliction (AD&amp;D)"

                  abbrev="Disease" 

                  role="Article" 

                  family_id="12" 

                  asset_name="Virus"

                  asset_uuid="5400287B-91C6-5D3A-00D0-6A935C3C6BA9"

                  original_uuid="AFF995B6-BC31-1C61-9280-6893DE566BA9"

                  signature="986972">

            <description/>

            <summary/>

            <partition partition_id="Partition_467" 

                       name="Overview"

                       original_uuid="B0F995B6-BC31-1C61-9280-6893DE566BA9"

                       signature="986973">

                <description/>

                <purpose/>

            </partition>

        </category>

Running both the "preserved" and "unpreserved" files through diffzilla (built into SlickEdit) it appears there isn't an explicit "preserve owner" xml attribute. Instead, the original_uuid get the first six digits of the GUID changed during the export process. This is what pointed me to examine the custom elements for conflicts. It was interesting that the exporter altering these GUIDs is enough to tell the importer these are new elements rather than existing ones.

Code:

        <category category_id="Category_79" 

                  name="Malady/Affliction (AD&amp;D)"

                  abbrev="Disease" role="Article" family_id="12" asset_name="Virus"

                  asset_uuid="5400287B-91C6-5D3A-00D0-6A935C3C6BA9"

                  original_uuid="E6248BB6-BC31-1C61-9280-6893DE566BA9"

                  signature="986972">

            <description/>

            <summary/>

            <partition partition_id="Partition_437" 

                       name="Overview"

                       original_uuid="E7248BB6-BC31-1C61-9280-6893DE566BA9"

                       signature="986973"><description/>

                <purpose/>

            </partition>

        </category>

At any rate, with these breadcrumbs, I was able to manually remove the unneeded tags from the file and run an import on a test realm (a copy of the realm having import problems) successfully.

I'm now going through the process of ensuring I'm only using the tags I want, and clearing out any custom Categories/Tags I didn't personally create via the UI, and making individual exports based on the groupings I want (source books/modules).

Once that's done I'm going to run another set of import tests. I'll let you know how it goes.

I found that while the initial imports work a 2nd import from the same source will fail for some reason, so beware of that (even w/o any changes). This error might be a dealbreaker for the whole import export business of the tool. the error was added in one of the latest versions, there is a separate thread about it. So I am interested how your next round of testing goes. I hope it'll work :)

Even with only my 8 custom categories, exporting a "clean" structure file, and 4 "clean" preserved exports (PHB, MM, DMG and UA), I'm still getting "Parameter is not valid" after the second import file (MM). However if I import the unpreserved versions, I get duplicates for 5 of these categories (I'd have expected to get dupes for all 8).

The weird thing is that my MM import duplicated the Spell category, but there are no spell articles in that export. However, it didn't duplicate the Character, Deity or Psionic Discipline categories, which don't have articles either. Seems inconsistent.

I'm checking to see if the dupes created are consistent across all 4 import files.

Something that comes to mind as I write this: I wonder if maybe some of the articles aren't reset to the final category structure? I know I was evolving them as I was working on the data so some of them might not conform to the full section/order configuration.

I'll have to check that out after I (possibly) narrow the field further.

I'll keep at it.

OK, now I think I'm smoking something, because I went back to a clean realm + structure, and imported each of the 4 preserved files, this time without any issues!

Going to see if there's something I missed. Perhaps the order of import???

Hmmm...

Here's the order I did it this time:

New + Structure
PHB
MM
DMG
UA

The UA file has the DMG and PHB files flagged as dependencies. I *believe* I did it last time in the same order, but now I'm second guessing myself. I also don't recall getting a modal complaining about missing dependencies.

Going to try again with a new realm mucking with the order to now see if I can generate a specific repro scenario for the Parameter is not valid error.

When you perform a subsequent import, the global_uuid or original_uuid is what RW uses to match up the item with what is already in the database.

Thus, from your investigation, doing an export with "preserve" enabled and a second one with "preserve" disabled will generate two different sets of uuids. So then importing both into a new realm should generate duplicates of everything (since the 2nd import will not find matching uuids).

The uuids in the "<structure>" section of the file should be identical across all your various export files; since there is a single structure in your realm. I haven't specifically checked the global_uuid values, but I would hope that these are the same for any still-locked category definitions across all realms created from the same "game type" choice.

I found one, final, errant category that, after removing allowed my core imports to all succeed.

Now, I'm hitting a new issue.

I have an adventure that I've created an export for, that also has a Storyboard. If I export it without the storyboard, it imports to the target realm successfully.

As soon as I apply the export tag to the storyboard, run a new file and then try to import it (preserving ownership), it hits an Object reference exception.

I've verified all associated content for the plot points only point to articles with the export tag. There are a few items in the plot without associated content.

I'm going to setup a test plot with a single, unassociated point and see if that imports correctly.

Then, I'll associate an article and see what happens.

Baby steps :)

On second thought, I figured I'd check the (2nd import of the same file) bug previously mentioned, as that might explain the Object ref error I just hit.

So yea, importing the file that succeeded the first time, blew chunks the second.

I'm syncing back to the point prior to the module import and seeing if I can bring in the storyboard version.

Will let you know.

Well, the full storyboard came in when there was no previous version of the module in the target Realm.

Are update imports 100% broken, or is it just for specific scenarios? Anyone know?

Imho it's completely broken, since you can import from one Realm only a single time.
It works if you use a 2nd newly created realm in between, but really, it does not sound like it's viable. Unless this error can be fixed in the import files / some workaround, the whole feature is broken, as you cannot really update data and would have to clean up duplicates etc. Easier to work in a single realm imho.

I'm dropping back to 253 to see if the update scenario works for me there. In reading the revision notes for 254 (and 255) I'm not sure the bug they fixed in 253 affected me in the first place.

I've read in another thread here where reversion fixed the person's issue, so I'll see.

I've wiped the realm DB from %AppData%, uninstalled/reinstalled 253, then clean synced to bring down the realm data.

Setup version notes on my structure export and all 6 of my content exports and am now assembly-lining the exports.

The test plan is:

1. create a new realm with structure
2. import new versions of export files.
3. make an origin change
4. create and then import an updated export file.

Side note: Wouldn't it be awesome if, when importing files, you could point to an export file and RW would show you the content notes *before* you decided to bring it in?

Updates pending...

WootNESS!

Worked like a charm. Now I know 2 things:

my realm/exports are finally clean and updatable (sp?)
I'm staying on 253.

Thanks for listening.

How do you drop back to 253 - I always get a "newer database" error when using anything older than 254. Basically it sounds like I need to have the server access to be able to do the downgrade?

Quote:

Originally Posted by Acenoid (Post 289118)

How do you drop back to 253 - I always get a "newer database" error when using anything older than 254. Basically it sounds like I need to have the server access to be able to do the downgrade?

Make a backup of your masterrealm file and then try to delete it. Or while your at it, delete whole Realm Works folder from %APPDATA%\LWD Technology, Inc\

That should do the trick.

Quote:

Originally Posted by Acenoid (Post 289118)

How do you drop back to 253 - I always get a "newer database" error when using anything older than 254. Basically it sounds like I need to have the server access to be able to do the downgrade?

That or a copy of your database from 253 or below.

Okay, I don't have that anymore :) Server access expired some time ago ... hrm maybe I'll ask support.