Micros EM Package Out of Sequence

[stratobastard]

I have a case where EM packages have gotten out of sequence on my 5.0 EM server. Em is expecting to receive package 58, but the store generated package 59. I'm sure this is just a case of 58 getting lost somewhere in my FTP scripting. I have recovered in the past by digging into SQL, but that can be somewhat messy. Is there a 'clean' way to get a store back in synch on the EM server?

Thanks for any insight.

 

[DJensen999]

The SQL method is the only one I know of. Had to use it extensively prior to starting our 5.0 upgrade process.

 

[Bogg3r]

Can you not just do a receive.exe -F to do a force receive on the EM server? Could have sworn I've done that before to fix the same issue but I may be imagining things.

 

[DJensen999]

I've done that with clients before, but haven't tried it on the server...

 

[Moregelen]

Can you not recover the missing packet? And yes, you should be able to do a forced receive on the server without problem.

 

[stratobastard]

Thanks for all the replies so far. Here's the situation. The RES Deployment package (expected EM Receive package) was deleted before it was received by on the EM server. So I have an outstanding EM Deploy package waiting to be received and RES Deployment packages that are being deemed out of sequence. I can't believe that Micros hasn't implemented an easy way to get things back in line as I'm sure that this happens all the time. But then again, I know of a few concepts who don't even care about keeping EM send/receive in synch. As long as you are certain that changes were deployed, its just house keeping. I just like to see all green checks when I look at the status in EM.

 

[stratobastard]

Is there a way to regenerate a specific packet on the RES server?

 

[Moregelen]

No - thats why we tend to use something like DropBox to transfer the files. Even if it gets deleted, we can recover the file if necessary. If you force it through on the EM server, eventually it will disappear off the list. You can speed that up by decreasing the visible history. That way you can get your nice check marks.

 

[stratobastard]

My wish list:

C:\micros\res\em\bin\receive.exe -regen_package -n S128_D1_C1_P58.mpz -just_do_it

 

[stratobastard]

Actually...

C:\micros\res\em\bin\deployment.exe -regen_package -n S128_D1_C1_P58.mpz -just_do_it

 

[Moregelen]

Lol. I suppose if you wanted to get clever with it (and time consuming) you could stage a database backup from right before the receive on a lab, and do the receive and then deployment to recover your package

 

[Moregelen]

It isn't really that big of a deal. SO long as it received successfully on the store side its just a cosmetic thing at that point.

 

[stratobastard]

You are right. Thanks. I have reached out to my Micros rep to see how exactly they have dealt with this with other customers. As I said, I'm sure this happens all the time and keeps us POS admins up at night who like to keep things tidy. I'll post the results of that communication as hear back.

 

[Moregelen]

I've had it happen to me before - can't remember why dropbox didn't have a backup. I just forced through the next package and ignored the warning for the few weeks it took to disappear from my history.