Bạn hiện đang ngoại tuyến, hãy chờ internet để kết nối lại

Giải đáp thắc mắc DBCC lỗi 2570 trong SQL Server 2005 và phiên bản mới nhất

QUAN TRỌNG: Bài viết này được dịch bằng phần mềm dịch máy của Microsoft chứ không phải do con người dịch. Microsoft cung cấp các bài viết do con người dịch và cả các bài viết do máy dịch để bạn có thể truy cập vào tất cả các bài viết trong Cơ sở Kiến thức của chúng tôi bằng ngôn ngữ của bạn. Tuy nhiên, bài viết do máy dịch không phải lúc nào cũng hoàn hảo. Loại bài viết này có thể chứa các sai sót về từ vựng, cú pháp hoặc ngữ pháp, giống như một người nước ngoài có thể mắc sai sót khi nói ngôn ngữ của bạn. Microsoft không chịu trách nhiệm về bất kỳ sự thiếu chính xác, sai sót hoặc thiệt hại nào do việc dịch sai nội dung hoặc do hoạt động sử dụng của khách hàng gây ra. Microsoft cũng thường xuyên cập nhật phần mềm dịch máy này.

Nhấp chuột vào đây để xem bản tiếng Anh của bài viết này:923247
GIỚI THIỆU
Bài viết này mô tả SQL Server lỗi 2570, những gì gây ra lỗi, và làm thế nào để giải quyết vấn đề.
THÔNG TIN THÊM

Kiểm tra DATA_PURITY

Trong SQL Server 2005, một lựa chọn mới, DATA_PURITY, đã được thêm vào DBCC CHECKDB và DBCC CHECKTABLE lệnh. Khi bạn thực hiện một CHECKDB DBCC hoặc DBCC CHECKTABLE lệnh với tùy chọn này được kích hoạt, lệnh sẽ thực hiện "dữ liệu độ tinh khiết" validations trên mỗi giá trị cột trong tất cả các hàng của bảng hoặc bảng trong cơ sở dữ liệu. Những kiểm tra mới được thực hiện để đảm bảo rằng các giá trị được lưu giữ trong các cột là hợp lệ (có nghĩa là, mà các giá trị không phải là out-of-range cho tên miền liên kết với loại dữ liệu cột). Các bản chất của xác nhận được thực hiện phụ thuộc vào kiểu dữ liệu cột. Các sau khi danh sách không đầy đủ cho một số ví dụ:
Cột kiểu dữ liệuLoại dữ liệu xác nhận được thực hiện
Ký tự UnicodeĐộ dài dữ liệu cần một bội số của 2.
DateTimeLĩnh vực ngày cần giữa tháng một 1 1753 31 tháng mười hai 9999. Lĩnh vực thời gian phải sớm hơn '11:59:59:999 PM'.
Thực tế và phaoKiểm tra sự tồn tại của không hợp lệ các giá trị điểm nổi như SNAN, QNAN, NINF, ND, PD, PINF.
Không phải tất cả các loại dữ liệu được đánh dấu cho hiệu lực của cột dữ liệu. Chỉ có những nơi có thể có một giá trị được lưu trữ mà là ra khỏi phạm vi được kiểm tra. Ví dụ, các tinyint kiểu dữ liệu có một phạm vi hợp lệ 0 qua 255 và được lưu trữ trong một đơn byte (trong đó chỉ có thể lưu trữ các giá trị từ 0 đến 255), do đó kiểm tra giá trị là không cần thiết.

Kiểm tra xác nhận độ tinh khiết của dữ liệu chưa được bật tự động cho tất cả các cơ sở dữ liệu. Kiểm tra được kích hoạt phụ thuộc vào một số yếu tố:
  • Đối với cơ sở dữ liệu tạo trong SQL Server 2005 và phiên bản mới nhất, các chi phiếu được kích hoạt theo mặc định và không thể được vô hiệu hóa, do đó, việc sử dụng các tùy chọn DATA_PURITY khi thực hiện một lệnh DBCC CHECKDB hoặc DBCC CHECKTABLE là không thích hợp.
  • Đối với cơ sở dữ liệu được tạo trong phiên bản trước của SQL Hệ phục vụ, chẳng hạn như SQL Server 2000, SQL Server 7.0 và các phiên bản nâng cấp lên SQL Microsoft SQL Server 2005, kiểm tra những không được kích hoạt theo mặc định. Để kiểm tra các để được thực hiện, bạn phải chỉ định các tùy chọn DATA_PURITY trong DBCC CHECKDB hoặc DBCC CHECKTABLE lệnh. Điều này có thể dẫn đến hai điều:
    • DBCC lệnh kết thúc và báo cáo rằng cơ sở dữ liệu được sạch sẽ, trong đó có tất cả các dữ liệu kiểm tra độ tinh khiết. Thực tế này được ghi lại trong các cơ sở dữ liệu tiêu đề. Tất cả các tiếp theo DBCC CHECKDB hoặc DBCC CHECKTABLE lệnh xử tử sẽ thấy thông tin này và sẽ tự động thực hiện dữ liệu kiểm tra độ tinh khiết, như sẽ xảy ra đối với cơ sở dữ liệu tạo trên SQL Server 2005. Trong nói cách khác, một khi cơ sở dữ liệu được biết đến là "sạch sẽ," kiểm tra dữ liệu độ tinh khiết là luôn luôn thực hiện.
    • DBCC lệnh kết thúc nhưng báo cáo vấn đề về dữ liệu không thống nhất. Nếu đây là trường hợp, bạn sẽ phải làm sạch cơ sở dữ liệu để loại bỏ những mâu thuẫn và sau đó cố gắng để thực thi lệnh DBCC một lần nữa. Bạn sẽ phải chỉ định các tùy chọn DATA_PURITY cho lệnh DBCC cho đến các cơ sở dữ liệu được báo cáo để được làm sạch.
  • Nếu tùy chọn PHYSICAL_ONLY được xác định khi DBCC CHECKDB hoặc DBCC CHECKTABLE lệnh được thực thi, kiểm tra độ tinh khiết của dữ liệu không thực hiện.

TRIỆU CHỨNG

Dữ liệu không hợp lệ hoặc ra phạm vi có thể đã được lưu trữ trong SQL Máy chủ cơ sở dữ liệu trong các phiên bản trước đó vì lý do sau:
  • Dữ liệu không hợp lệ đã được hiện diện trong các nguồn trong khi sử dụng số lượng lớn chèn phương thức, chẳng hạn như các tiện ích bcp.
  • Dữ liệu không hợp lệ đã được truyền qua RPC sự kiện cuộc gọi được thực hiện cho SQL Server.
  • Tiềm năng khác gây ra tham nhũng dữ liệu vật lý trái các giá trị cột trong trạng thái không hợp lệ.
Nếu bạn có dữ liệu không hợp lệ trong một cột một bảng, bạn có thể gặp vấn đề tùy thuộc vào loại hoạt động được thực hiện đối với các dữ liệu không hợp lệ. Tuy nhiên, cũng có thể rằng không có vấn đề sẽ xuất hiện, và các dữ liệu không hợp lệ sẽ không được phát hiện cho đến khi bạn thực hiện một DBCC CHECKDB hoặc DBCC CHECKTABLE lệnh SQL Server 2005 và phiên bản mới nhất.

Một số các triệu chứng bạn có thể nhận thấy nhờ sự hiện diện của dữ liệu không hợp lệ bao gồm (nhưng không giới hạn tới):
  • Hành vi vi phạm quyền truy cập hoặc các loại ngoại lệ trong khi đang thực hiện truy vấn đối với các cột bị ảnh hưởng.
  • Không chính xác kết quả trở lại bởi truy vấn thực hiện đối với các ảnh hưởng cột.
  • Lỗi hoặc các vấn đề khi số liệu thống kê đang được xây dựng với các cột bị ảnh hưởng.
  • Thông báo lỗi như sau:
    Msg 9100, Cấp 23, bang 2, Line 1 có thể chỉ mục tham nhũng được phát hiện. Chạy DBCC CHECKDB.

Báo cáo vấn đề DATA_PURITY

Khi bạn thực hiện một lệnh DBCC CHECKDB hoặc DBCC CHECKTABLE với tùy chọn DATA_PURITY kích hoạt (hoặc kiểm tra độ tinh khiết dữ liệu đang chạy tự động), và dữ liệu không hợp lệ tồn tại trong bảng kiểm tra bởi DBCC lệnh, sản lượng DBCC bao gồm bổ sung thư này chỉ ra các vấn đề với các dữ liệu. Một số mẫu thông báo lỗi rằng chỉ ra sự tinh khiết dữ liệu vấn đề được hiển thị dưới đây:
DBCC kết quả cho "account_history".
Msg 2570, cấp 16, bang 2, dòng 1
Trang (1:1073), khe 33 trong đối tượng ID 1977058079, chỉ số ID 0, phân vùng ID 129568478265344, đơn vị alloc ID 129568478265344 (loại "dữ liệu trong hàng"). Cột "account_name_japan" giá trị nằm ngoài phạm vi cho kiểu dữ liệu "nvarchar". Cập nhật các cột một giá trị pháp lý.
Msg 2570, cấp 16, bang 2, dòng 1
Trang (1:1156), khe 120 trong đối tượng ID 1977058079, chỉ số ID 0, phân vùng ID 129568478265344, alloc đơn vị ID 129568478265344 (kiểu "Trong hàng dữ liệu"). Cột "account_name_japan" giá trị là ra phạm vi cho kiểu dữ liệu "nvarchar". Cập nhật các cột một giá trị pháp lý.
Có đang 153137 hàng trong 1080 trang cho đối tượng "account_history".
CHECKDB được tìm thấy 0 phân bổ các lỗi và 338 sự đồng bộ lỗi trong bảng "account_history" (đối tượng ID 1977058079).
CHECKDB tìm thấy phân bổ 0 lỗi và 338 sự đồng bộ lỗi trong cơ sở dữ liệu 'BadUnicodeData'.
DBCC thực hiện hoàn thành. Nếu DBCC in thông báo lỗi, liên hệ với người quản trị hệ thống của bạn.
DBCC kết quả cho 'table1'.
Msg 2570, cấp 16, Bang 3, dòng 1
Trang (1:154), khe 0 trong đối tượng ID 2073058421, chỉ số ID 0, phân vùng ID 72057594038321152, đơn vị alloc ID 72057594042318848 (loại "Trong hàng dữ liệu"). Cột "col2" giá trị nằm ngoài phạm vi cho kiểu dữ liệu "thực sự". Cập nhật các cột một giá trị pháp lý.
Có 4 hàng bằng 2 trang cho đối tượng "table1".
CHECKDB tìm thấy phân bổ 0 lỗi và nhất quán 1 lỗi trong Bảng 'table1' (đối tượng ID 2073058421).
CHECKDB tìm thấy lỗi phân bổ 0 và nhất quán 1 lỗi trong cơ sở dữ liệu 'realdata'. DBCC thực hiện hoàn thành. Nếu DBCC in lỗi tin nhắn, liên hệ với người quản trị hệ thống của bạn.
DBCC kết quả cho 'table2'.
Msg 2570, cấp 16, Bang 3, dòng 1
Trang (1:155), khe 0 trong đối tượng ID 2105058535, chỉ số ID 0, phân vùng ID 72057594038452224, đơn vị alloc ID 72057594042449920 (loại "Trong hàng dữ liệu"). Cột "col2" giá trị nằm ngoài phạm vi cho kiểu dữ liệu "thập phân". Cập nhật các cột một giá trị pháp lý.
Có 4 hàng bằng 1 trang cho đối tượng "table2".
CHECKDB tìm thấy phân bổ 0 lỗi và nhất quán 1 lỗi trong Bảng 'table2' (đối tượng ID 2105058535).
CHECKDB tìm thấy lỗi phân bổ 0 và nhất quán 1 lỗi trong cơ sở dữ liệu 'realdata'. DBCC thực hiện hoàn thành. Nếu DBCC in lỗi tin nhắn, liên hệ với người quản trị hệ thống của bạn.
DBCC kết quả cho 'table3'.
Msg 2570, cấp 16, Bang 3, dòng 1
Trang (1:157), khe 0 trong đối tượng ID 2121058592, chỉ số ID 0, phân vùng ID 72057594038517760, đơn vị alloc ID 72057594042515456 (loại "Trong hàng dữ liệu"). Cột "col2" giá trị nằm ngoài phạm vi cho kiểu dữ liệu "datetime". Cập nhật các cột một giá trị pháp lý.
Có 3 hàng bằng 1 trang cho đối tượng "table3".
CHECKDB tìm thấy phân bổ 0 lỗi và nhất quán 1 lỗi trong Bảng 'table3' (đối tượng ID 2121058592).
CHECKDB tìm thấy lỗi phân bổ 0 và nhất quán 1 lỗi trong cơ sở dữ liệu 'realdata'. DBCC thực hiện hoàn thành. Nếu DBCC in lỗi tin nhắn, liên hệ với người quản trị hệ thống của bạn.
Cho mỗi hàng có chứa một giá trị không hợp lệ cột, một lỗi 2570 được tạo ra.

Sửa chữa vấn đề độ tinh khiết của dữ liệu

2570 Lỗi không thể được sửa chữa bằng cách sử dụng bất kỳ sửa chữa DBCC tùy chọn. Điều này là bởi vì nó không thể cho DBCC để xác định những gì giá trị nên sử dụng để thay thế giá trị không hợp lệ cột. Vì vậy, giá trị cột phải là tự Cập Nhật.

Để thực hiện một Cập Nhật bằng tay, bạn phải tìm hàng có vấn đề. Có hai cách để thực hiện việc này.
  • Thực hiện một truy vấn đối với bảng chứa các các giá trị không hợp lệ để tìm các hàng có chứa các giá trị không hợp lệ.
  • Sử dụng các thông tin từ 2570 lỗi để xác định các hàng có giá trị không hợp lệ.
Chúng tôi sẽ thảo luận về cả hai của những phương pháp này chi tiết dưới đây, bằng cách sử dụng Ví dụ để tìm các hàng có dữ liệu không hợp lệ.

Một khi bạn tìm thấy các chính xác liên tiếp, một quyết định cần phải được thực hiện trên các giá trị mới sẽ được sử dụng để thay thế dữ liệu không hợp lệ hiện có. Quyết định này đã được thực hiện rất cẩn thận dựa trên phạm vi giá trị mà làm việc cho các ứng dụng cũng như những gì làm cho tinh thần hợp lý cho rằng hàng cụ thể của dữ liệu. Những lựa chọn bạn có là:
  • Nếu bạn biết những gì giá trị nó nên là, đặt nó vào đó giá trị cụ thể.
  • Đặt nó vào một giá trị được chấp nhận mặc định.
  • Thiết lập giá trị cột để NULL.
  • Thiết lập giá trị cột với giá trị tối đa hoặc tối thiểu cho kiểu dữ liệu cột.
  • Nếu bạn cảm thấy rằng hàng cụ thể là không sử dụng bất kỳ mà không cần một giá trị hợp lệ cho các cột, bạn có thể xoá hàng đó hoàn toàn.

Việc tìm kiếm hàng với các giá trị không hợp lệ bằng cách sử dụng T-SQL Queries

Loại truy vấn mà bạn cần phải thực hiện để tìm kiếm hàng mà có giá trị không hợp lệ phụ thuộc vào kiểu dữ liệu cột báo cáo một vấn đề. Nếu bạn xem xét các thông báo lỗi 2570, bạn sẽ nhận thấy hai phần quan trọng của thông tin sẽ giúp bạn với điều này. Trong ví dụ sau, cột "account_name_japan" giá trị nằm ngoài phạm vi cho kiểu dữ liệu "nvarchar." Chúng tôi có thể dễ dàng xác định các cột có vấn đề cũng như kiểu dữ liệu của các cột tham gia. Do đó, một khi bạn biết các dữ liệu nhập và các cột có liên quan, bạn có thể xây dựng các truy vấn để tìm các hàng có chứa các giá trị không hợp lệ cho rằng cột, chọn các cột cần thiết để xác định rằng hàng (như predicates trong một WHERE khoản) cho bất kỳ tiếp tục Cập Nhật hoặc xóa bỏ.

Kiểu dữ liệu Unicode:
SELECT col1 ,DATALENGTH(account_name_japan) as Length ,account_name_japan FROM account_historyWHERE DATALENGTH(account_name_japan) % 2 != 0

Thả nổi loại dữ liệu:
-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from the CHECKDB outputSELECT col1, col2 FROM table1WHERE col2<>0.0 AND (col2 < 2.23E-308 OR col2 > 1.79E+308) AND (col2 < -1.79E+308 OR col2 > -2.23E-308)

Kiểu dữ liệu thực tế:
-- Change col1 to your actual primary key column(s), col2 to the column from the 2570 error, table1 to the table from -- the CHECKDB outputSELECT col1, col2 FROM testReal WHERE col2<>0.0 AND (col2 < CONVERT(real,1.18E-38) OR col2 > CONVERT(real,3.40E+38)) AND (col2 < CONVERT(real,-3.40E+38) OR col2 > CONVERT(real,-1.18E-38)) ORDER BY col1; -- checks for real out of range
Thập phân và số kiểu dữ liệu:
SELECT col1 FROM table2WHERE col2 > 9999999999.99999 OR col1 < -9999999999.99999
Hãy nhớ rằng bạn sẽ cần phải điều chỉnh các giá trị dựa trên các độ chính xác và quy mô mà bạn đã xác định các thập phân hoặc số cột. Trong ví dụ trên, các cột được định nghĩa là col2 decimal(15,5).

Nay dữ liệu thời gian loại:
Bạn sẽ cần phải thực hiện hai truy vấn khác nhau để xác định các hàng có chứa các giá trị không hợp lệ cho ngày thời gian cột.
SELECT col1 FROM table3WHERE col2 < '1/1/1753 12:00:00 AM' OR col2 > '12/31/9999 11:59:59 PM'SELECT col1 FROM table3 WHERE((DATEPART(ms,col2)+ (1000*DATEPART(s,col2)) + (1000*60*DATEPART(mi,col2)) + (1000*60*60*DATEPART(hh,col2)))/(1000*0.00333)) > 25919999

Việc tìm kiếm hàng với giá trị không hợp lệ bằng cách sử dụng địa điểm:

Bạn có thể sử dụng phương pháp này nếu bạn không thể tìm thấy các hàng của lãi suất sử dụng phương pháp T-SQL thảo luận ở trên. Trong các thông báo lỗi 2570, các Địa điểm của hàng có chứa giá trị không hợp lệ được in. Cho Ví dụ, xem xét thông báo sau:
Trang (1:157), khe 0 trong đối tượng ID 2121058592, chỉ số ID 0, phân vùng ID 72057594038517760, đơn vị alloc ID 72057594042515456 (loại "dữ liệu trong hàng"). Giá trị cột "col2" ra khỏi phạm vi cho kiểu dữ liệu "datetime". Cập Nhật cột để một pháp lý giá trị.
Trong thư này, bạn sẽ thấy các thông tin: Trang (1:157), khe 0. Đây là những thông tin bạn cần để xác định các hàng. FileId là 1, PageInFile là 157, và SlotId là 0. Một khi bạn đã thông tin này, bạn sẽ cần phải thực hiện lệnh, như sau:
DBCC TRACEON ( 3604 )DBCC PAGE ( realdata , 1 , 157 , 3 )
Lệnh này sẽ in toàn bộ nội dung của một trang. Các tham số cho các DBCC trang lệnh là:
  • cơ sở dữ liệu tên
  • FileId
  • PageInFile
  • tùy chọn in Ấn
Một khi bạn thực hiện lệnh này, bạn sẽ nhận thấy sản lượng mà chứa các thông tin tương tự như định dạng sau:
Slot 0 Offset 0x60 Length 19 Record Type = PRIMARY_RECORD Record		  Attributes = NULL_BITMAP Memory Dump @0x44D1C060 00000000: 10001000 01000000		  ffffffff ffffffff †................ 00000010:		  0200fc†††††††††††††††††††††††††††††††... Slot 0 Column 0 Offset 0x4 Length 4 col1 = 1Slot 0 Column 1 Offset 0x8 Length 8 col2 = Dec 31 1899 19:04PM Slot 1 Offset 0x73 Length 19 Record Type = PRIMARY_RECORD Record		  Attributes = NULL_BITMAP Memory Dump @0x44D1C073 00000000: 10001000 02000000		  0ba96301 f8970000 †..........c..... 00000010:		  0200fc†††††††††††††††††††††††††††††††... Slot 1 Column 0 Offset 0x4 Length 4		  col1 = 2 Slot 1 Column 1 Offset 0x8 Length 8 col2 = Jul 8 2006 9:34PM Slot 2		  Offset 0x86 Length 19 Record Type = PRIMARY_RECORD Record Attributes =		  NULL_BITMAP Memory Dump @0x44D1C086 00000000: 10001000 03000000 0ba96301		  f8970000 †..........c..... 00000010: 0200fc†††††††††††††††††††††††††††††††...		  Slot 2 Column 0 Offset 0x4 Length 4 col1 = 3 Slot 2 Column 1 Offset 0x8 Length		  8 col2 = Jul 8 2006 9:34PM 
Sản lượng này bạn có thể thấy rõ các giá trị cột cho hàng của bạn quan tâm. Trong trường hợp này, bạn cần hàng được lưu trữ trong khe 0 trang. Từ các thông báo lỗi, bạn biết col2 đó là một trong các vấn đề. Vì vậy, bạn có thể mất giá trị của col1 cho Khe 0 và sử dụng nó như predicate trong WHERE khoản tuyên bố của bạn Cập Nhật hoaëc Xoùa tuyên bố.

CẢNH BÁO Chúng tôi đề nghị bạn sử dụng các phương pháp đầu tiên (nghĩa là, sử dụng T-SQL truy vấn để tìm thông tin cần thiết). Sử dụng trang DBCC lệnh chỉ như là một cuối cùng. Hãy chăm sóc tối ưu trong khi bạn sử dụng lệnh này trong một sản xuất môi trường. Nó được khuyến khích để khôi phục lại cơ sở dữ liệu sản xuất trên một bài kiểm tra máy chủ, sau đó nhận được tất cả thông tin cần thiết bằng cách sử dụng DBCC trang, và sau đó làm việc bản Cập Nhật trên máy chủ sản xuất. Như mọi khi, hãy chắc chắn để giữ một bản sao lưu sẵn sàng trong trường hợp điều gì sai trái và bạn cần phải trở lại một bản sao trước đó của các cơ sở dữ liệu.
THAM KHẢO
Để biết thêm chi tiết về các báo cáo DBCC CHECKDB, xem chủ đề "DBCC CHECKDB (Transact-SQL)" vào các nhà phát triển Microsoft sau Trang Web mạng (MSDN): Để biết thêm thông tin về được biết đến các vấn đề trong SQL Server 2000, nhấp vào số bài viết sau đây để xem các bài viết trong cơ sở kiến thức Microsoft:
900335Khắc phục: Chiến dịch phục hồi tự động cơ sở dữ liệu SQL Server 2000 có thể không thành công nếu chỉ có một kiểu dữ liệu PHAO hoặc một loại dữ liệu thực tế, và loại dữ liệu có chứa một giá trị NaN
Để biết thêm chi tiết về các sự kiện RPC, xem các "Kêu gọi một thủ tục lưu trữ (OLE DB)" chủ đề trên MSDN Web site sau:Để biết thêm chi tiết về các loại dữ liệu khác nhau, xem các "Kêu gọi một thủ tục lưu trữ (OLE DB)" chủ đề trên MSDN Web site sau:Để biết thêm chi tiết về nổi điểm giá trị công ước, truy cập vào Intel Web site sau: Microsoft cung cấp thông tin liên lạc bên thứ ba để giúp bạn tìm hỗ trợ kỹ thuật. Thông tin này có thể thay đổi mà không báo trước. Microsoft không đảm bảo sự chính xác của thông tin liên lạc bên thứ ba này.

Cảnh báo: Bài viết này được dịch tự động

Thuộc tính

ID Bài viết: 923247 - Xem lại Lần cuối: 03/22/2012 20:52:00 - Bản sửa đổi: 1.0

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Express Edition with Advanced Services, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Enterprise Edition for Itanium-based Systems, Microsoft SQL Server 2005 Enterprise X64 Edition, Microsoft SQL Server 2005 Standard Edition for Itanium-based Systems, Microsoft SQL Server 2005 Standard X64 Edition, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Express with Advanced Services, Microsoft SQL Server 2008 Workgroup, Microsoft SQL Server 2008 Standard Edition for Small Business

  • kbtshoot kbexpertiseadvanced kbsql2005engine kbinfo kbmt KB923247 KbMtvi
Phản hồi