Probably going to have to recut databases because of this issue but thought I'd check for alternatives just in case.

The issue is that we have data (opportunities) that was written to the host DB that did not get pushed out to remote clients.  We used the SLX OLE/DB provider but made the mistake of fully qualifying table names to include the DB name.  So...when the SQL insert statements got pushed to the remote clients they choked because the remote DBs have different names than the host DB (i.e. SalesLogix vs SLXRemote).

The code has been fixed, so the bleeding has stopped, but we have a set of opportunities that exist on the host DB that won't synch out to the remotes.  I tried writing a utlitity that would move all the opportunities to a temporary account that was not access by the remotes (updating opportunity account and seccodeid).  I then reran the utility assigning the opportunities to their original accounts.  The thought behind this was that it would send synch code to withdraw opportunities (that didn't really exist) and then push them out to the remote clients when re-assigned to the appropriate account and seccodeid.  I did full synch cycles between these changes but appears this method won't work...unless I'm missing something.

Any creative ideas out there on how to push these opportunities to the remote clients or is the consensus to redo the cuts?  I guess another idea would be to just delete the opportunities and just re-import them but that is getting into a little more work.

Thanks!

You could write a Utility that indeed Deletes the Opportunity and creates a new Instance, but that being the case, it may be easier for you to Re-Import them.

load the sql stmts into administrator execute sql utility and blast it to the remotes. Provided you have the script and its complete (with slx ID's), if not see option 2

option 1

- remove the "dbNamd.sysdba." using a search and replace and append a ";" to start of each line

replace "insert dbname.sysdba." with ";Insert " witll do it.

- Load the script into the administrator execute sql utility (one stmt / line) using load script or load text option.

- uncheck the host

- select the remotes - Do one first to test.

This will insert the sql into the sync system and bypass the checks.

option 2

unsubscribe the accounts in question or set of them and remove then from the remotes, Then push tham back out, note this purges all the data and can cause the sync server to spin for days, but is the correct method and simpler depending on volume and complexity of sync rules.