#044<<#045

СОВЕТЫ

Резервирование журнала транзакций базы данных Master не допустимо в SQL Server 2000
По материалам статьи Q285288 «INF Transaction Log Backups of Master Database Are Not Allowed». Содержание этой статьи относится к Microsoft SQL Server 2000.

Допускается только полное резервное копирование базы данных master. Если Вы создаете Database Maintenance Plan для всех системных баз данных или если Вы включаете в него базу данных master, и включаете резервирование её журнала (transaction log), как одну их подзадач Maintenance Plan, на этапе резервирования transaction log базы данных master Вы получите следующее сообщение об ошибке: «Backup can not be performed on this database. This sub task is ignored». В Simple Recovery model база данных master должна существовать, как база по умолчанию. Вы должны создать для неё отдельный Maintenance Plan, который не должен включать резервирование transaction log. Для других баз данных, у которых Вы хотите резервировать transaction log, при необходимости, создайте дополнительные планы.
Вы можете использовать для базы данных msdb модель Full Recovery и выполнять резервное копирование transaction log. Если recovery model для msdb установлен в «simple», резервная копия transaction log, включённая в Maintenance Plan, не будет выполнена. Вы увидите сообщение об ошибке, которое появится в разделе «Summary».
Для получения дополнительной информации о поддержке master и msdb баз данных, обратитесь к статьям: «Backing Up the Master Database» и «Backing Up the Model, MSDB, and Distribution Databases», входящим в Microsoft SQL Server 2000 Books Online.

Что делать, если журнал транзакций не очищается, даже после DUMP TRAN WITH NO_LOG
По материалам статьи Q184499 «INF Transaction Log Still Full After DUMP TRAN WITH NO_LOG». Содержание этой статьи относится к Microsoft SQL Server 6.0, 6.5

После получения сообщения об ошибке 1105, указывающей на то, что журнал транзакций (transaction log) полностью заполнен, Вы должны выполнить следующую команду, которая усекает transaction log:

dump transaction <db> with no_log

Где <db> - имя базы данных, указанной в сообщении об ошибке 1105.

Эта статья рассматривает шаги, которые Вы должны предпринять, если вышеупомянутая команда не очищает transaction log.
Если, после выполнения этой команды, transaction log всё еще остаётся заполненным, Вам необходимо убедится, что информация о свободном месте в журнале транзакций, полученная с помощью SQL Enterprise Manager (SEM), Windows NT Performance Monitor или sp_spaceused, действительно верна и актуальна. Неправильное отображение информации о величине заполнения журнала вызвано существованием ошибки, которая описана в статье:
Q183100: PRB: Incorrect Log Size Reported in SEM or Performance Monitor
Рассмотрим вопрос обновления информации о заполненности журнала к актуальному состоянию, в качестве маленького отступления.
Суть статьи Q183100 в том, что после усечения переполненного transaction log, информация о количестве свободного места журнала, хранящаяся в системной таблице sysindexes, может не соответствовать реальному состоянию. Вызвано это, во первых, тем, что таблица sysindexes не обновляется непрерывно, поскольку это могло привести к существенному падению эффективности. Во вторых, Обновление информации в этой таблице, как и любой другой таблицы базы данных, является регистрируемой в transaction log операцией. Когда transaction log переполняется, модификация sysindexes становится невозможной, в чём и состоит причина неточности содержащейся в ней информации.
Чтобы разрешить эту проблему, выполните следующую инструкцию после усечения файла регистрации:

DBCC CHECKTABLE (syslogs)

В ответ, Вы получите отчёт, пример которого представлен ниже:

Checking syslogs
The total number of data pages in this table is 1.
The number of data pages in Sysindexes for this table was 4. It has been corrected to 1.
The number of rows in Sysindexes for this table was 128. It has been corrected to 12.
*** NOTICE: Space used on the log segment is 0.00 Mbytes, 0.10.
*** NOTICE: Space free on the log segment is 2.05 Mbytes, 99.90.
Table has 12 data rows.
DBCC execution completed. If DBCC printed error messages, see your System Administrator.

Используемое и свободное место в журнале, после этого, будет показано правильно, потому что DBCC CHECKTABLE проследит все фактические цепочки страницы transaction log. Обратите внимание на эту строку отчёта:

The number of rows in Sysindexes for this table was 128. It has been corrected to 12.

Это говорит о том, что DBCC CHECKTABLE также обновляет и значения таблицы sysindexes. Команда DBCC CHECKTABLE должна исправить информацию о свободном месте в базах и журналах, которая отображается в SQL Enterprise Manager или Performance Monitor. Однако, иногда Вам потребуется для получения правильного результата выполнить ещё одну инструкцию:

DBCC UPDATEUSAGE (<db_name>)

ОБРАТИТЕ ВНИМАНИЕ: DBCC UPDATEUSAGE может работать очень долго. Эта команда обновляет значения dpages в sysindexes для всех таблиц в базе данных, не только для syslogs.

После этой инструкции, отображение занимаемого места должно быть точным. Если это не так, пробуйте запустить команду CHECKPOINT, чтобы зафиксировать те изменения, которые ещё находятся в кэше. Также, можно использовать кнопку Recalculate в SQL Enterprise Manager. Обратите внимание, что эта кнопка запустит автоматическое исполнение DBCC UPDATEUSAGE, что может потребовать продолжительного исполнения. Для получения подробной информации о свободном месте в базах данных и журналах, используйте команду:

DBCC SQLPERF (logspace)

На этом наше маленькое отступление можно считать законченным, и мы вернёмся к первоначальной теме настоящей статьи.

Если после применения вышеперечисленных команд:

USE <databasename>
GO
DBCC CHECKTABLE (syslogs)
GO
DBCC UPDATEUSAGE (<db_name>)
GO
CHECKPOINT
GO
DBCC SQLPERF (logspace)
GO

Вы все-таки видите, что журнал транзакций переполнен (99.99 процентов), проверьте возможные причины, следствием которых могло стать это переполнение. Возможные причины и способы их устранения были представлены в прошлом выпуске рассылки, в статье Причины заполнения журнала транзакций SQL серверов 4.2x, 6.0, 6.5, 7.0

ОБРАТИТЕ ВНИМАНИЕ: Если dump transaction не усекает большую часть Вашего transaction log, причиной этого можете быть открытая транзакция. Определить наличие открытых/активных транзакций можно с помощью:

USE <databasename>
GO
DBCC OPENTRAN (<databasename>)
GO

В ответ, Вы получите отчёт, пример которого представлен ниже:

Transaction Information for database: pubs
No active open transactions.
Replicated Transaction Information:
Oldest Distributed RID_____: (0 , 0)
Time Stamp______________: 0001 0000000E
Oldest Non-Distributed RID_: (589 , 26)
Time Stamp______________: 0001 0000363E
DBCC execution completed. If DBCC printed error messages, see your System Administrator.

В представленном примером отчёте открытых транзакций не зафиксировано, но если таковые будут обнаружены, необходимо дождаться их завершения и повторить попытку очистки журнала транзакций. Заметьте, что отчёт указывает на отсутствие открытых транзакций, но в блоке Replicated Transaction Information есть строки дополнительной информации, которые показывает, что база данных была отмечена для репликации. Если будет выдана информация о репликации, убедитесь, что значение Oldest Distributed Transaction RID близко к Oldest Non-Distributed RID. Их отличие говорит о том, что существует репликация, выполняющийся в настоящее время для этой базы данных. Количественное различие будет основано на ряде переменных, относящихся к репликации, которые выходят за рамки этой статьи. Вам достаточно понять,   что база данных отмечена для репликации и существуют записи в transaction log, которые этой репликацией используются.

ВАЖНО: При обнаружении активной репликации, Вы сначала должны определить, почему транзакции, отмеченные для репликации, не завершены. Продолжить дальнейшую работу по очистке журнала Вы можете только после того, когда обеспечите и убедитесь, что эта база данных не участвует в репликации. Для получения дополнительной информации, см. SQL SERVER BOOKS ONLINE или статью в Microsoft Knowledge Base: Q89937: INF: Getting Started with Microsoft SQL Server Replication.

Для проверки отсутствия активной репликации, выполните следующий сценарий:

USE master
GO
sp_helpserver
GO

В ответ, Вы получите отчёт, пример которого представлен ниже:

name_______network_name_____status________id
-----------------------------------------------------------------
CYGNUS____CYGNUS_________pub,sub,dis___0

Отчёт отобразит роль Вашего сервера в репликации. Если поле status пустое, сервер в репликациях не участвует. Помните, что сервер может участвовать в репликации, но Вы должны убедиться, что база данных с переполненным журналом в этих репликациях не участвует:

SELECT name, category FROM master..sysdatabases
WHERE name = '<databasename>'
GO
USE <databasename>
GO
--The query will return all objects that are published (32) or
--replicated (64)
SELECT category FROM sysobjects
WHERE type = 'U' and category & 32 = 32 or category & 64 = 64

В ответ, Вы получите отчёт, пример которого представлен ниже:

name_______category<
--------------------------
pubs________0

(1 row(s) affected)

Информация, отображаемая в поле category, показывает, как база данных участвует в репликации. Если поле категории содержит 0, это означает, что база данных не издается.
Поле category выдаёт информацию об объектах. Если Вы получаете нулевое количество строк, как показано ниже, это означает, что ни одна из таблиц не включен в репликацию.

name_______category
---------------------------

(0 row(s) affected)

Помните, что Вы не удаляете репликацию, а только проверяете, что не существует никаких объектов в этой базе, которые отмечены для репликации. Если такие объекты существуют, Вы не должны пытаться очистить transaction log; Вы должны вначале определить, почему транзакции, отмеченные для репликации, не завершены.
Если репликация для этой базы данных всё-таки была завершена, Вы, возможно, имеете в transaction log распределённые транзакции. Это может остаться от репликации, которая был установлена на этом сервере ранее, и она не была удалена полностью. Чтобы решать эту проблему, попробуйте следующий сценарий:

USE master
GO
sp_configure 'allow', 1
GO
reconfigure with override
GO
BEGIN TRAN
UPDATE master..sysdatabases set category = 1 where name = '<databasename>'
-- verify that the correct row has been changed by running
-- select name, category from sysdatabase where name = '<databasename>'
-- if the correct row is changed then run the following
COMMIT TRAN

Этим Вы отметили базу данных, как участвующую в репликации. Вы можете определять любые транзакции в журнале, что бы указать их для репликации, как распределённые.

sp_repldone 0, 0, NULL, 0, 0, 1

Эта хранимая процедура, хорошо описана в SQL SERVER BOOKS ONLINE. Рассмотрим то, что эта команда делает:
Когда page = 0, row = 0 и reset = 1 все репликационные транзакции в журнале отмечаются, как распределённые. Это полезно, когда есть репликационные транзакции в transaction log, от которых нужно избавится (например, реплицируемая таблица была удалена), после чего, Вы хотите произвести усечение журнала транзакций. Например, после того, как указанная выше хранимая процедура успешно отработала, Вы можете попытаться очистить transaction log с помощью:

DUMP TRAN <databasename> WITH NO_LOG

Для проверки состояния журнала транзакций, выполните следующую команду:

DBCC CHECKTABLE(syslogs)

Transaction log должен теперь быть пуст.

ОБРАТИТЕ ВНИМАНИЕ: поскольку Вы очистили transaction log, Вы должны выполнить полное резервное копирование вашей базы данных, иначе записи журнала не возможно будет выносить в резервную копию. Обратитесь к SQL SERVER BOOKS ONLINE для получения дополнительной информации по восстановлению и резервирование баз данных.
После завершения очистки журнала необходимо вернуть изменённые настройки в исходное состояние:

-- Set any object marked for replication as not published or replicated
UPDATE sysobjects set category = category & ~32
UPDATE sysobjects set category = category & ~64
USE master
GO
-- Set the database as not published update sysdatabases set category = 0 where name = '<databasename>'
sp_configure 'allow',0
GO
RECONFIGURE with override
GO

ЗАМЕЧАНИЕ АВТОРА РАССЫЛКИ: Но, если даже после всех, представленных выше манипуляций, Ваш журнал транзакций останется не очищенным, можно применить совсем уже кардинальное средство. Попробуйте уменьшить размер базы данных средствами Enterprise Manager до минимально – возможного размера. Если свободного места в базе много, но Enterprise Manager не даёт значительно уменьшить размер, это говорит о высокой фрагментации данных. Вам придётся провести дефрагментацию данных, варианты которой уже рассматривались в рассылке. После этого уменьшение размера базы должно быть значительным. Далее, перегрузите или перестартуйте сервер и верните размер базы к первоначальному состоянию. Если после этого повторить описанные в статье Микрософт процедуры, журнал регистрации транзакций должен очиститься. Не знаю почему, но иногда только такая встряска позволяет избавится от застрявших в журнале записей.

Некоторые недокументированные хранимые процедур SQL Server 7.0
По материалам статьи Александра Чигрик на swynk.com «SQL Server 7.0 Useful undocumented stored procedures»

Sp_columns_rowset

Эта хранимая процедура возвращает описание столбцов, включая длину, тип, имя, и так далее. Синтаксис:

sp_columns_rowset tbname [, table_schema ] [, column_name]

Пример использования:

USE pubs
GO
EXEC sp_columns_rowset 'authors'
GO

Sp_fixindex

Эта хранимая процедура используется для устранения повреждений в системных таблицах, выполняет переиндексацию. Синтаксис:

sp_fixindex database, systemcatalog, ind_id

Где:
database - имя базы данных.
systemcatalog - системное имя таблицы.
ind_id - идентификатор индекса (intNote).

Перед использованием этой хранимой процедуры, база данных должна быть переведена в однопользовательский режим. См. эту статью для получения дополнительной информации: "How can I fix a corruption in a system table?"
http://www.windows2000faq.com/Articles/Index.cfm?ArticleID=14051

Пример использования:

USE pubs
GO
EXEC sp_fixindex pubs, sysindexes, 2
GO

Sp_MSexists_file

Эта хранимая процедура определяет, существует ли специфический файл в заданном каталоге. Синтаксис:

sp_MSexists_file full_path, filename

Где:
full_path - nvarchar (512), имя пути к файлу.
filename - nvarchar (255), имя файла.

Для проверки, существует ли файл textcopy.exe в каталоге C:\MSSQL7\BINN\ (путь по умолчанию), выполните:

DECLARE @retcode int
EXEC @retcode = sp_MSexists_file 'C:\MSSQL7\BINN\', 'textcopy.exe'
IF @retcode = 1 PRINT 'File Exist'
ELSE PRINT 'File does not Exist'

Sp_MSforeachdb

Иногда, Вы должны выполнить однотипные действия для всех баз данных. Можно для этой цели создать курсор, но также можно использовать sp_Msforeachdb, например, чтобы проверить все базы данных командой DBCC CHECKDB:

EXEC sp_MSforeachdb @command1="print '?' DBCC CHECKDB ('?')"

Sp_MSforeachtable

Иногда, Вы должны выполнить однотипные действия для всех таблиц в базе данных. Можно для этой цели создать курсор, но также можно использовать sp_MSforeachtable, например, чтобы восстановить все индексы в базе:

EXEC sp_MSforeachtable @command1="print '?' DBCC DBREINDEX ('?')"

Выполнение этой инструкции можно запланировать на то время, когда база не сильно загружена.

Sp_MShelpcolumns

Эта хранимая процедура возвращает схему таблицы, включая длину, тип, имя, и вычисляемый ли столбец. Синтаксис:

sp_MShelpcolumns tablename [, flags] [, orderby] [, flags2]

Где:
tablename - nvarchar (517), имя таблицы.
flags – int, флаг, со значением по умолчанию 0.
orderby - nvarchar (10), со значением по умолчанию NULL.
flags2 - int, со значением по умолчанию 0.

Чтобы получить полное описание столбцов таблицы authors в базе pubs, выполните:

USE pubs
GO
EXEC sp_MShelpcolumns 'authors'
GO

Sp_MShelpindex

Эта хранимая процедура возвращает информацию об: имени, состоянии, fillfactor, именах индексных столбцов и о используемой файлгруппе для данной таблицы. Синтаксис:

sp_MShelpindex tablename [, indexname] [, flags]

Где:
tablename - nvarchar (517), имя таблицы.
indexname - nvarchar (258), имя индекса.
flags – int, флаги, со значением по умолчанию NULL.

Получить описание индексов для таблицы authors в базе данных pubs, можно так:

USE pubs
GO
EXEC sp_MShelpindex 'authors'
GO

Sp_MShelptype

Эта хранимая процедура возвращает много полезной информации о системных и пользовательских типах данных. Синтаксис:

sp_MShelptype [typename] [, flags]

Где:
typename - nvarchar (517), имя типа, со значением по умолчанию NULL.
flags - nvarchar (10), флаги со значением по умолчанию NULL.

Чтобы получать информацию обо всех системных и определяемых пользователем типах данных в базе данных pubs, выполните:

USE pubs
GO
EXEC sp_MShelptype
GO

Sp_MSindexspace

Эта хранимая процедура возвращает размер в КБ, который используют индексы в выбранной таблице. Синтаксис:

sp_MSindexspace tablename [, index_name]

Где:
tablename - nvarchar (517), имя таблицы.
index_name - nvarchar (258), - имя индекса.

Определить размер занимаемого индексами места в таблице authors базы данных pubs можно так:

USE pubs
GO
EXEC sp_MSindexspace 'authors'
GO

Sp_MSkilldb

Эта хранимая процедура устанавливает базе данных признак suspect (подозрительная) и, используя средства dbcc dbrepairto, уничтожает её. Вы должны выполнять эту процедуру в контексте базы данных master. Используйте её очень осторожно. Синтаксис:

sp_MSkilldb dbname

Где:
dbname - nvarchar (258), имя базы данных.

Уничтожить базу данных pubs можно так:

USE master
GO
EXEC sp_MSkilldb 'pubs'
GO

Sp_MStablespace

Эта хранимая процедура возвращает число строк и величину занимаемого таблицей и индексами места. Синтаксис:

sp_MStablespace [name] [, id]

Где:
name - nvarchar (517), имя таблицы.
id – int, идентификатор, со значением по умолчанию NULL.

Определить используемое место таблицей authors в базе данных pubs, можно так:

USE pubs
GO
EXEC sp_MStablespace 'authors'
GO

Sp_tempdbspace

Эта хранимая процедура может использоваться, чтобы получить полный размер базы данных tempdb и процент его использования. Вы должны запустить sp_tempdbspace без параметров. Синтаксис:

EXEC sp_tempdbspace

Sp_who2

Эта хранимая процедура возвращает информацию о текущих пользователях и отрабатывает так же, как sp_who, но обеспечивает более детальную информацию. sp_who2 возвращает CPUTime, DiskIO, LastBatch и ProgramName в дополнение к sp_who. Синтаксис:

sp_who2 [loginame]

Где:
loginame - имя пользователя. Если оно не указывается, процедура возвращает информацию обо всех активных пользователях. Пример:

EXEC sp_who2 'sa'

ГОТОВИМСЯ К ТЕСТУ ПО 70-028

ШПАРГАЛКА #9 Продолжение (обзор официального курса Microsoft)
Архив шпаргалок Вы найдёте на следующих сайтах:
http://www.sql.ru/subscribe/
http://subscribe.ru/archive/comp.soft.winsoft.sqlhelpyouself

Средства и способы мониторинга SQL сервера

Задача исследования производительности SQL сервера и выявления узких мест решается намного проще, если Вы будете использовать системный подход. Столкнувшись с тем, что Ваша СУБД работает не так производительно, как Вы ожидали или производительности неожиданно снизилась, без видимых на то причин, необходимо последовательно локализовать проблему, которая стала этому виной.
Стандартное руководство Микрософт предлагает начать поиск проблемы или узкого места на системном уровне, а уже после этого на уровне клиентского приложения и отдельного запроса. Это можно объяснить тем, что низкая производительность приложения баз данных может быть не следствием проблем SQL сервера, а вызвана перегрузкой дисковой подсистемы, высокой утилизацией процессора или памяти. Причиной перегрузки дисковой подсистемы может быть, к примеру, высокое число запросов на подкачку страниц. Для того, что бы судить о том, высока ли утилизация одного из используемых системой ресурсов, необходимо представлять, какие значения его утилизации являются допустимыми, а какие низкими или высокими. Выяснить допустимые диапазоны производительности логично до начала промышленной эксплуатации системы (используя модель рабочей нагрузки), и периодически их корректировать по мере роста или модификации составных компонентов системы. Ясное и точное представление о допустимых диапазонах значений имеющихся в Вашем распоряжении счётчиков производительности поможет Вам быстро локализовать неисправности или находить узкие места, даже в тех случаях, когда причиной возникновения проблемы в одной области могут быть проблемы   из другой области, или они их маскируют. Например, один из используемых компонентов может мешать передаче рабочей нагрузки на другой компонент. Или проблемы в сети могут не давать клиентам подключиться к серверу или очень сильно увеличивать время отклика. Также, на производительность сервера могут оказывать негативное влияние узкие места клиентских программ. После перевода системы в промышленную эксплуатацию, стандартное руководство рекомендует составить базовый профиль производительности, в который включаются основные параметры реальной работы системы, а также часы максимальной загрузки пользователями базы данных, реальное время отклика запросов или пакетных файлов, время резервирования/восстановления баз данных и т.п. Базовый профиль можно сравнить с допустимыми диапазонами, что бы выяснить, производительность каких систем или компонент оказалась не достаточно высока.
На всех этапах мониторинга производительности системы в Вашем распоряжении будут шесть инструментальных средств, входящих в базовый комплект поставки Microsoft SQL Server. Для мониторинга на уровне системы используют Microsoft Event Viewer и SQL Server Performance Monitor. Для мониторинга операций Microsoft SQL Server и работы его компонент (блокировки, коллизии, подключения, утилизация tempdb, согласованность данных) используют такие средства, как: SQL Server Profiler, окно Enterprise Manager - Current Activity, системные хранимые процедуры, специальные операторы T-SQL, операторы DBCC. Для исследования производительности отдельных запросов (использование индексов, утилизация запросом процессора, объём I/O) применяют SQL Server Query Analyzer и Index Tuning Wizard.

Продолжение следует.

ПОЛЕЗНОСТИ

Статья А. Мнацаканян «SQL- запросы в Базах Данных Microsoft Jet». Процессор Баз Данных Microsoft Jet, обрабатывающий все запросы SQL языка Visual Basic соответствует стандарту SQL-89 и имеет незначительные различия на втором и третьем уровне.
http://sql.ru/articles/article.php?id=4

Новые технические статьи Microsoft

Q295742 - BUG: UPDATE Statement Using a SELECT with Aggregates and JOIN May Generate Internal Error
Q295724 - PRB: Nonlogged BCP Operation Can Be Logged on Tables with Indexes and Existing Data
Q294371 - BUG: Cubes and Dimensions Not Visible After Upgrading From OLAP Services 7.0 to Analysis Services 8.0
Q281983 - PRB: Cannot Specify Instance Name Using SQL Server 2000 Merge Modules
Q286082 - PRB: Attach/Detach Menu Commands Unavailable Against SQL Server 7.0
Q289290 - BUG: DBCC SHRINKDATABASE Causes Memory Leak and Error 17803 When AUTO_SHRINK Is Set
Q294412 - BUG: SQLAgent T-SQL Job Does Not Respect SET NOCOUNT ON When Sending Output to File
Q294453 - INF: How to Set Up SQL Server 2000 to Listen on Multiple Static TCP Ports
Support WebCast: Microsoft SQL Server 2000: Merge Replication Enhancements
Q288910 - PRB: "Invalid Class String" Error When Opening DTS Package
Q201240 - HOWTO: Put Stored Procedures Under Source Control in Visual InterDev
Support WebCast: Understanding User-Defined Functions in Microsoft SQL Server 2000

ФОРУМ SQL.RU: ДЮЖИНА САМЫХ ПОПУЛЯРНЫХ ТОПИКОВ НЕДЕЛИ

MS SQL ADO
Как сравнить 2 базы с одинаковой структурой. Только не говорите, что ручками
Макроподстановка в Select ...
Вопрос по работе insert или триггера
Размещение файлов данных на сетевом устройстве
Как передать в процедуру TEXT-параметр
Какая-то непонятка творится с временными таблицами
Чтение файлов в T-SQL
где можно найти
Вычисляемые поля в процедуре
Error details
поиск по множеству таблиц

ФОРУМ SQL.RU: ВОПРОСЫ ОСТАЛИСЬ БЕЗ ОТВЕТА

проблемы с рефрешем при использовании View в Delphi
Как использовать поле Image
QA в MSSQL 2000
Где можно взять документалово(обращение из Пёрла к MSSQL)
Microsoft SQL Workstation (локальный MSSQL)
Ошибка при Merge replication
MSSQL Oracle
Как в MSSQL 7 сделать правильную кириллицу под Win2000?
Вернемся к MSSQL 2000
Вызов ActiveX из SP (дополненное и переработанное)!
Отладка SP в SQL 2000
Как связать таблицу из Sybase SQL Anewhere 5.0 с MS SQL7
DataTransfer
Вызов ActiveX из SP (не работает sp_OAMethod). Помогите разобраться!
MS SQL7 vs MS SQL 2000

#044<<#045