We have an issue with some Users not getting (AND Maintaining) the correct, most recent version of a plugin.  We have had this problem occasionally, off and on for several years… used to only happen 2-3 times a year – so no huge problem.  Now it’s happened to 5 users just this week.  We have one user that it has happened to, EVERY Day for the last 3 days.  She comes in in the morning, works for a couple of hours just fine, then all of a sudden – an old version of a view becomes the current active version for just her UserID.  Everybody else is still getting the correct, most current version.  Somebody else can log into SLX on the user having the problems workstation, and that user will get the right/current version of the view.  It is beyond a doubt, a “user specific” issue.  This problem, at least as far back as I can remember, always involves the same plugin, which happens to be a custom View.  It also happens to be the largest, in terms of complexity, objects, scripts associated with it, etc. custom View that we have.

 We have tried the following steps to fix this issue for these users:

1. Deleting the “C:\Program Files\Interact Commerce\SalesLogix\Sales Client\cache” folder from the affected users workstation.  This DOES NOT fix the problem. 


2. Deleting the “C:\Documents and Settings\username\Application Data\Interact Commerce” folder from the affected users machine.  DOES NOT fix the problem. 


3. Rebuilding the sec rights cache DOES NOT fix the problem. 


4. All of our views and scripts are released to “Everyone”.  But we have tried releasing the problematic view specifically to the person having the problem also – and this DOES NOT fix the problem.

 We have performed all 4 of the above steps together for an effected User and it does not fix the problem.

 The ONLY thing we have done, that to-date, fixes it every time we have tried it, is to:

a)     Delete the affected Users profile off the workstation,

b)     Delete their user profile off the network (we use roaming profiles). 

c)      Then we delete the cache folder

d)     have the User log back on and the problem is fixed. 

Up until this past Wednesday, this procedure fixed the problem for the given user – permanently.  But now we have one user, that for some reason, it only fixes it temporarily for her.  So far, once we fix it for her during the day, she is OK the rest of the day.  Logs out, logs off at the end of the day, comes in the next day – problem is back after she has been working a while.

any ideas?  anybody else ever seen this problem?

I've seen this problem at firms that can't afford individual workstations for users.....

Also seen this problem in versions prior to 5.2.6.....

Are the users closing out of saleslogix completely when they walk away from the workstation?

There are only two versions of each plugin in 5.2 right? The ADMIN version and the released version(s)? we've seen problems with this 'back in the day'...much better too have a different plugin than a different release....

using slxprofiler identify the plugin id of the problem view/form and them look at the records accociated with it in the plugin table.

It is possible to have a old release that is not attached to parent anymore. The only way to fix this is to delete the pluginid via sql.  

so, find the pluginid and I'll bet then basedon id does not exist anymore, its an orphan release. Othertimes the parent does exist but for some reason it was not revoked during an upgrade or during releases of the current version of the form. 

Another option;

Select * from plugin where Family=? and Name=? and userid<>'ADMIN'

This should be a list of the releases. join in the parent using the basedon id to pluginid again and the release name using userid to seccodeid

check the versions and/or dates and you should find the problem.  

At least this has always worked for me.

Another trick is to always delete the plugin cache off the slxprovider and user desktops after an upgrade. You can join the directory file names back to the plugin table to identify either things that you know should not be used or more often to identify what sections of slx nobody has been using.

all of our users have their own workstations . 

Our users don't normally logout of SLX and close it down until the end of the day - when they leave - at which time they are instructed to restart their machines - and most of them do.

We only see two versions of each plugin in the plugin table.  But somehow... the older versions exist somewhere - or so it appears, because for this user, and others in the past, we can clearly see that their userid is using the older version of the vie - even after we delete the entire cache folder from their workstation.

this plugin, queried by name, has two entries in the plugin table as follows(we just recreated it last Thu. to see if that would help - note that SLX kept the createdate of the Very first time this view was created but changed the modifieddate)... I see no problem here, except I'm not sure how version 2 gets a pluginID value less than the value for pluginID for version 1...

pluginid                  name       version      basedon                 family         createdate                            modifieddate
pPB2OA00016Q      SM_Refill   2              NULL                      Personal      2003-04-14 16:03:23.490      2011-02-10 13:59:54.870
pPB2OA00016R      SM_Refill   1              pPB2OA00016Q       Personal      2003-04-14 16:03:23.490      2011-02-10 13:59:30.340

once the problem starts, the problem will follow the user from workstation to workstation - doesn't matter where they go, once they the problem, they have the problem at all workstations.  It is user specific to their Userid and follows them via their Network Roaming profile it would appear.

I don't understand what you are saying to do about joining to --> "and the release name using userid to seccodeid" ?.  Where in the SLX tables, can we see what version of a pluginID is released to a given userid?

I'm not sure of the sql you used here to get this, but either the data is incomplete or somethings wrong in the problem definition. The legacy view is in the plugin table, it has to be. The issue is locating it.

Another query you might try is: select * from plugin where basedon = 'pPB2OA00016Q'. If there are other form with the basedon id, they might be pulled in, the record with userid=admin and basedon=null is the dev copy. the basedon field is the link to the releases and the userid field is the released to key

but i would also run the sql processed by the provider to load the form as detailed in slxprofiler. This will bring back lots of rows (including developer copyed of the form not released but created under that users profile) based on index order the top most record is used and loaded. A caching issue affects all users on the pc, a profile specific issue would point to the DEV flag. Example, if I have a sql selection statement where the where and order by criteria return duplicate data for 6 rows, which record will be first, and therfore used by slx? This is dependent on indexing in most cases and would appear to be arbitrary and would/could change over time. If you run the load sql from slxprofiler, then review all the rows returned you can figure out what pluginid's need to be deleted from the table.

the sql was simply a select * from sysdba.plugin where name = 'SM_Refill'.  Every plugin in our plugin table has two rows...with the same name, one with userid ADMIN and one with userid SYST00000001.  One with basedon = null and one with basedon valued to the pluginID of the other row with the same name.  What is almost unique about this particular plugin is that the version is not the same on both rows... for about 99% of our other plugins the version number is the same on both rows.  We have 250 slx users... right now - only this one user has this issue at the moment.  About 80 users use this particular problematic view all day long, every day.  This view/plugin is released to everybody - its accessed thru a menu that is only released to the 80 users that need it.  And what is really bizarre about this one user is once we delete her network profile, have her log back into her machine, she will be able to work in SLX just fine the rest of the day.  She logs off, goes home, comes back the next day, able to work in SLX 2-3 hours OK, then all of a sudden, in an instant, she's back to the old version of the view.

select * from plugin where basedon = 'pPB2OA00016Q' returns only the row for 'pPB2OA00016R'

another tidbit of info that might be useful, is that normally we do not "develop" in this database.  We have a copy of our production database on a physically separate server - we do our development there, bundle from there and then install on the production box.  Only in the cases where a plugin has been created and/or edited on the production server and then released there after editing do we see different version numbers. 

I "hear you" about the old version of the plugin has to be "somewhere"... but its not in the plugin table.  I have come to learn that SLX can be installed, and used a lot of different ways over my 8 years of working with it.  I don't know what SLX does with the old version of a plugin when we install/release a new version via an installation bundle, but we do not see more than two rows for any plugin we have in our plugin table.  The modifydate gets updated, the version number gets updated and the data column I assume, but as for where the old version/release of the code actually goes - I have no idea - we do not see them in our plugin table.  I just looked at one of our other custome views; Version number is 705, but there are still only two rows in the plugin table for this plugin.name - and version # happens to be 705 on both rows.

Also, where this problem manifests itself on the problematic view, is that a script tied to an event on a grid tries to reference a column that is not in/on the grid in the old/previous version of the view.  It is a column that we recently added to this grid on this view.  We have a error trap, "If LogixErrors" after the statement.

we are probably down to sifting thru a massive amount of data from the profiler....

Check the "SyncPath" for the Dev box......I've seen stranger things happen......

Confirm that you are NOT synching Dev changes......