So my previous post on the subject appears to have disappeared But anyway we are getting the following error when trying to extract SOME users Local Databases.
DBCLog DBCLogError 1 00000101522d5e3c:0 2013-09-09 14:20:46 [Microsoft][SQL Native Client][SQL Server]Index "S_STORE_COND_U1" on table "dbo.S_STORE_COND" (specified in the FROM clause) is disabled or resides in a filegroup which is not online.
GenericLog GenericError 1 00000101522d5e3c:0 2013-09-09 14:20:49 (smisched.cpp (911) err=1376333 sys=0) SBL-SMI-00077: Component error, see the trace file for more information
As I managed to re-extract a test user, when then created a brand new position (with no data) and assigned that to one of the problem users.
Then, the re-extract worked OK.
So..it seems to me there is a data problem with some of the data associated with these User(s).
I don't expect anyone here can 'solve' that; but does anyone have some pointers on what to look at next?
I've checked and the user is associated with 4 Assignment Rules..
The Table mentioned S_STORE_COND (interestingly or maybe not, not sure) doesn't have any DOCKING rules..?
There is certainly Accounts (2650) and Orders (650) associated with the problem position (for instance there is records in S_ACCNT_POSTN, S_ORDER_POSTN
Short of going through each individual record with a fine tooth comb I'm not sure what to look out for?
Running that SQL gives:
Server: Msg 315, Level 16, State 1, Line 1
Index "S_STORE_COND_U1" on table "S_STORE_COND" (specified in the FROM clause) is disabled or resides in a filegroup which is not online.
If this was a general problem with this 'Index', then surely it would affect:
- Online usage.
- All Remote Clients on All Remote Servers.
Wheras the case seems to be it:
- Doesn't affect online usage at all.
- Only affects some Remote Clients on some Remote Servers..
Also, does anyone know if its a valid thing to do to get the DBA's to simply rebuild this Index? I mean, is it going to affect Siebel in some way?
& how could this really have happened, I mean, everything was working before..?
We can also turn this the other way around.
Because you see the same error when you execute the SQL directly, it's not (specifically) related to Siebel.
Your DBA has to come up with an explanation or solution for the error message.
Not all users will see the same data, so the fact that not all users see this error message still isn't proof of a bug in Siebel.
Working with the DBA we had the Index re-instated in QA, were we had the same issue.
So far it seems to have 'fixed' the problem; Database Extracts can run through again even for 'broken' remote clients.
No one seems to be able to explain what happened to our Index, which is strange to me, as it seems unlikely that someone manually disabled it.
But I'll just have to put it down as 'one of those things' I suppose.