|
|
|
Возвращение веры 2
|
|||
|---|---|---|---|
|
#18+
Доброго всем времени суток ! Помогите понять странное поведение SQL Server’а. Как обойти это , я уже нашел, но вот понять - никак... Итого: SQL Server 2000 Standard Edition на MS Windows 2000 Server, стоят все сервис-паки (админ за этим бдит). Есть две таблицы (слегка упрощенный вид ): 1) CREATE TABLE Object Base2.dbo.Objects ( [Nr] [int] IDENTITY (1, 1) NOT NULL , [ClientID] [int] NULL , -- = = = = = = = = = = = -- Здесь прочие поля -- = = = = = = = = = = = [ClientObjectID] [nvarchar] (50) NULL , [ClientObjectID2] [nvarchar] (50) NULL , ) ON [PRIMARY] CREATE UNIQUE INDEX [object1] ON [dbo].[Objects](Nr) WITH FILLFACTOR = 90 ON [PRIMARY] GO CREATE INDEX [object4] ON [dbo].[Objects](ClientID) WITH FILLFACTOR = 90 ON [PRIMARY] CREATE INDEX [object19] ON [dbo].[Objects](ClientObjectID2) ON [PRIMARY] 2) CREATE TABLE Base1.dbo. Table1_temp ( ObjektID nvarchar(10) NULL , Week int NULL , Date_from smalldatetime NULL , Date_to smalldatetime NULL ) ON [PRIMARY] GO CREATE INDEX [IX_Table1_temp] ON [dbo].[Table1_temp](ObjektID) WITH FILLFACTOR = 90 ON [PRIMARY] GO В таблице Objects примерно 30000 записей, из них под условие выборки попадает примерно 2300, в таблице Table1_temp - от 0 до примерно 50000, под выборку попададает не менее 90% . Проблема в том что один и тот же SELECT с INNER JOIN возвращает неодинаковые результаты при исполнении в Query Analyzer и в stored procedure , если в таблице Table1_temp более 20-25 тысяч записей. Запрос в QA возвращает все полностью, SP часть записей теряет SELECT DISTINCT O.Nr, C.Date_From, C.Date_To, 3 AS LockType FROM Base1.dbo.Table1_temp C INNER JOIN Base2.dbo.Objects O ON C.ObjectID = O.ClientObjectID2 WHERE O.ClientID = 8913 Пока выкрутился тем , что поставил SELECT внутрь курсора и выполняю выборку для каждого уникального ObjectID. Кто-нибудь сталкивался с чем-то подобным ? Или может подсказать , почему SP себя так ведет ? Буду признателен за любую помощь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2002, 12:56:15 |
|
||
|
Возвращение веры 2
|
|||
|---|---|---|---|
|
#18+
Чтобы одинаковые возвращало, необходимо чтобы настройки ANSI_NULLS и ANSI_PADDINGS были одинаковые или писать так запрос, чтобы эти настройки не имели значения (рекомендуется). А эти настройки, очевидно, разные, а запрос написан так, что эти настройки имеют большое влияние. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2002, 13:11:32 |
|
||
|
Возвращение веры 2
|
|||
|---|---|---|---|
|
#18+
2Dankov Спасибо за ответ, но это не помогло ... Поскольку NULL-значений в данных не было, включение или выключение ANSI_NULLS и ANSI_PADDINGS никак не отразилось на результате ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2002, 18:40:53 |
|
||
|
Возвращение веры 2
|
|||
|---|---|---|---|
|
#18+
И все-таки, ежели взять код Вашей процедуры и создать ее (в SQL Query Analyzer)под другим именем (для теста), предварительно выдав Код: plaintext 1. 2. 3. 4. При этом проверить, что обе настройки ON для запроса, проходящего "нормально" в SQL Query Analyzer - если они иные, то и для процедуры выставить аналогичные.... Далее вызвать процедуру (через SQL Query Analyzer, разумеется). Удачи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2002, 19:15:11 |
|
||
|
Возвращение веры 2
|
|||
|---|---|---|---|
|
#18+
и при этом не забыть ANSI_PADDINGS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2002, 09:57:00 |
|
||
|
Возвращение веры 2
|
|||
|---|---|---|---|
|
#18+
2Dankov: Насколько мне известно, опция ANSI_PADDING не сохранаяется "с процедурой". Во-вторых, каким образом данная опция может сказаться на выборке уже существующих данных? Во-третьих, видимо ANSI_PADDING . Удачи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2002, 11:17:35 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32050968&tid=1820234]: |
0ms |
get settings: |
6ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
42ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
29ms |
get tp. blocked users: |
1ms |
| others: | 224ms |
| total: | 322ms |

| 0 / 0 |
