next »

[JRV]

Download and install Microsoft SyncToy to:

(a) Make sure your Catalog, Textures, and other key Env data files are safe in the event of a hard drive crash, and will survive an Envisioneer upgrade.

(b) Use Env on 2 or more computers (but NOT simultaneously), such as a desktop at work and a notebook in the field, carrying the latest versions of these critical files with you.

(c) Centralize data storage on servers in accord with best IT practices.

SyncToy has evolved from, frankly, a useless mess, into a stable, efficient little application and it's perfect for this use. At this writing, it supports Windows XP, Vista and 7, x86 and x64. (I'm running it on Windows Server 2008 SP2 x64...shhhh, don't tell Microsoft.)

In IT, we NEVER allow user data to be stored on workstations. Only servers. Then it's safe, backed up, available--and the workstation becomes expendable. If a workstation hard disk dies, log on to another machine and pick up where you left off. Where needed, data is available to offline workstations through Offline Files. 

It's feasible to do this with all Envisioneer data files except the Catalog, which is completely incompatible with sound data management. So best practices have never applied to Envisioneer's most critical data file.

If you've ever tried storing your Catalog on a remote computer, you know that the, um, unusual way in which Envisioneer writes to the Catalog makes it impractical, and somewhat dangerous, to store there. SyncToy lets Envisioneer access the Catalog locally, but copy it off to the network promptly when you're done, letting you centralize your backups.

At this writing, you can download SyncToy from http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=c26efa36-98e0-4ee9-a7c5-98d0592d8c52.

I originally installed it on my notebook, but moved it to my server because the server will outlast this workstation. If you have multiple workstations and a server, it especially makes sense to put it on the server. Workstations come and go, but servers tend to be somewhat more long-lived, and are always turned on. And this centralizes SyncToy management.

When you set up synchronization, if the folder that includes CADSOFT.LIC is included, make sure to add an exclusion for that file. I don't know for sure, but I strongly suspect it's computer-specific and related to Env's copy-protection scheme, so you would not want to synchronize it to other computers.

I synch the entire Cadsoft folder, so I catch data for all past, present and future installed versions of Env. So I exclude CADSOFT.LIC.

To be useful, synchronization must be on auto-pilot, and this is the one part of SyncToy that's still poorly-implemented. There's no clue in the GUI that you can even do so, but it's documented in the Help file. Click Help/Learn how to schedule SyncToy. Set up SyncToy to run as a Scheduled Task (I have it run Daily at midnight, repeating every 5 minutes). Then it will grab files in near-real-time, as soon as Env releases them.

You won't even know when it's running; there's no detectable performance hit.

Hope this helps!

[FynrDzynr]

Thanks for that Jeff!

Can you be more specific re the catalogue?

Merv

[JRV]

Specific about what aspect of the catalog? I'll hazard a guess; if it's not want you want to know, please post again. Your question was short but the answer is pretty long, so I hope it's not in vain! But it inclues a little piece of Env's longstanding dirty laundry that deserves an airing from time to time.

If you think of the Catalog as a normal database, you have it all wrong. In a normal database, when data is changed, only the changed data is rewritten. It's very fast.

But when you save an Element, Env rewrites the ENTIRE catalog file, sequentially, starting from the first element and ending at the last. Every byte gets rewritten. Even if you just rename the Element to correct a 1-character (=1 byte) typo. That's OK for a small file, but as you know, the catalog is a VERY large file.

I suppose it eliminates fragmentation--but SQL Express could do the same thing by itself a lot more efficiently, and with many other benefits I've posted about here in the distant past. Must revive that thread. But that's a wishlist item, so I digress...

As long as they're going to rewrite the whole dang file every time, best practice would be for Env to write it to %TEMP%, which is guaranteed local, then rename the old catalog, move the new catalog to the final destination, and delete the backup copy. The final destination could then be a local or network drive with, well, maybe tolerable performance if you don't change the Catalog often.

The overhead that a network adds to all those tiny writes makes it take several minutes to save the file, even with gigabit. And if the computer crashes during that write, or the user terminates Env thinking that it's hung (because it will look like it is), the catalog will be incomplete. And you will be thoroughly hosed.

Try it: Back up your Catalog, then copy it to a network drive and tell Env the new location in Program Settings. Then add an Element and after you click OK, watch the remote folder in Explorer (keep pressing F5 to refresh). You'll see the file grow v-e-r-y s-l-o-w-l-y from 0 bytes to 35MB, or whatever the size of the file is. And if you terminate Env after 10MB is written, 10MB is all there will ever be<shiver>.

So that's where SyncToy comes in: The first time it fires after Env closes and releases the file handle on the Catalog, SyncToy swoops down and grabs a copy for the server.

Been using it a few weeks now and never a hiccup. YMMV. And it's unsupported by MS so consider yourself warned.

And I'll expand a bit on using SyncToy with 2 Env machines. SyncToy can do bi-directional syncs. So while I don't have 2 Env machines, it will help those who do. Say that \\MyDesktop changes the Catalog and 3 Textures. SyncToy running on \\MyServer grabs the Textures on its next run because they're not locked, and grabs the Catalog after Env closes. If \\MyNotebook is connected and running, SyncToy on \\MyServer copies the Catalog and Textures to it, so it's ready to go for your client meeting.

Just can't use the same data from 2 machines simultaneously; the last writer will win.

Now what we REALLY need is for Microsoft to provide a UI for us to configure DFS Replication, already built in to Vista & Win 7, for user data instead of just user profiles and offline files. That would be MUCH faster, and I don't think DFSR (which is configurable on Windows Server SKUs for replication between servers) is any harder than SyncToy. Or else call the DFSR API from SyncToy.

But that would be a Microsoft wishlist item, not a Cadsoft wishlist item! There I go again, designing Windows 8.