Replace corrupted server data

Somehow, all the SKU values in the server data got set to “0”.
(18,920 records)

I have an “unshared” database with good data in it.

How do I quickly move the good data from the unshared database to the shared database?

I’d rather not unshare the database with the bad data …

Walking the good database, record-by-record, and copying over seems like it would take many, many hours to complete.

Any quick, clever suggestions?

Thanks!

– Mark

So, it appears the SKU values were actually set to “5.64531981633163e-62” and not “0”

But, because it’s so small, Panorama displays it as “0” :man_shrugging:

If the records in the database with the good SKU’s can be matched to those in the database with the missing SKU’s, then the records can be “joined”, pulling the data over from the good to the missing. With 18,000 records, it should take about an eye blink. :slightly_smiling_face: - faster than record by record copy/paste or assignment via lookup. But I’m referring to two unshared files.

T’were it me, I’d break this into two tasks. 1) getting the SKU’s back in the database were they belong. 2) Sharing that database of it’s “friends” can be updated (assuming they are missing their SKU’s too).

In other words, my understanding doesn’t go much beyond getting data from records here into records there - without the complexity of sharing.

If I need to modify every record (or even a significant percentage of records) in a shared database, I would treat that the same way I would if I needed to change the field configuration (insert or delete a field). In other words, I would initiate a critical new generation to temporarily pause sharing. Then I would make whatever mass change I needed to make, and then finally finish the new generation process by uploading the new generation. This gives you the flexibility to use any Panorama technique you want to make the mass change. (I’m not sure why you are saying you’d rather not unshare the database, but I’d say this technique isn’t really unsharing the database, just pausing the sharing temporarily.)

This still leaves the question of how to quickly move data from one database to another. If there is a field that can be used as a key between the two databases, I would do this via a join. It should take less than a minute to set up and run the join.

However, I would guess that the SKU field would usually be the best candidate to use as a key field. Obviously that won’t work if the values are not valid. Hopefully there is some other field (or combination of fields) that can be used to uniquely identify each record.

I’m not sure I understand this idea anyway. How would you do the copy over? The two databases almost certainly aren’t in the same order. If you can get them in the same order then I think that means there is a unique key to be used for sorting, in that case you’d be better off just doing a join (which is basically a super fast way of walking the database - performed in Objective C code instead of Panorama code).

Hi Jim,

Thanks for the response.

I was hoping to save all the users the need to pull a new/fresh copy from the server.
It sounds like this might do that. Correct?

I had a local backup (from Time Machine) that had all the records, including SKUs, so I just needed to copy those records over to the “broken” copy of the database.

I could not just use my backup copy because as soon as it connects to the server, it synchronizes, and all the server data (with the “0” SKU values) overwrites the good data in my local copy. Hence the desire to quickly copy the data back over and push that up to the server.

If they’ve been sharing, the New Generation loads when they re-open their copies and the database synchs. There’s really no action they have to take.

By my experience the Critical and Non-Critical updates have been working quite well and my trust in them is high.

That’s exactly the situation that I faced this morning. I needed to restore data from a backup copy. How to do that without the backup synching and absorbing the “bad” data left me perplexed, but then the light went on. :bulb:

When I took the file offline via Critical New Generation, shared copies would no longer be able to synch. I could then open my backup safely, import the data from it and then finish the New Generation by uploading it - and all was well.

1 Like

Thanks, @JamesCook, for the confirmation!

Every day is a learning day … :slight_smile:

Actually, you can avoid that. Go to the Preferences window. In the Client pane, there is a checkbox to Disable Server Connections. Once that is turned on, you can open the database and it won’t sync. Then you could save it as a separate single user database. Then re-enable server connections, open the original database, start the new generation, copy the data over, then upload the new generation.

I’m still not sure what you mean by “copy the data back over.” Unless perhaps you mean you want to copy ALL of the data back over, and not just the SKU field. That would be easy.