2010-01-15 61 views
8

Điều này có vẻ giống như một câu hỏi thực sự ngớ ngẩn, nhưng tôi đã tìm kiếm xung quanh và tôi không thể tìm thấy bất cứ điều gì về điều này.Chỉ đọc các chuỗi kết nối DB

Tôi đã có một chuỗi kết nối DB mà tôi tạo ra trong web.config của tôi: -

<connectionStrings> 
<add name="DBConn" connectionString="Data Source=<db svr>;Initial Catalog=<dbname>;Integrated Security=True" providerName="System.Data.SqlClient /> 
</connectionStrings> 

hoặc

Data Source=<db svr>;Database=<db name>;User ID=<uname>;Password=<pword>; 

nhưng tôi cần kết nối này để được chỉ đọc. Tôi đã định nghĩa tất cả các đối tượng linq của mình chỉ với các thuộc tính của chúng, và không có lớp nào trong kho (MVC) của tôi có các phương thức .SubmitChanges() trong chúng nên tôi chắc chắn 99% hệ thống không thể cập nhật DB này, nhưng tôi cũng muốn đặt kết nối DB của tôi thành RO nếu có thể. Tôi nhận ra rằng lý tưởng này nên được thực hiện ở cuối máy chủ SQL và người dùng phải được tạo RO, nhưng (vì nhiều lý do khác nhau, ngoài tầm kiểm soát của tôi) không thể thực hiện được, vì vậy tôi muốn khóa kết nối của mình dưới dạng ứng dụng không được viết cho DB.

Có thông số "chỉ đọc" mà tôi có thể áp dụng cho chuỗi kết nối để nó có thể ném lỗi hoặc hủy dữ liệu nếu có bất kỳ cập nhật nào đã được thử không?

Chỉ cần nhắc lại (câu trả lời thứ nhất tôi có, khi yêu cầu điều này, trên diễn đàn khác là "thay đổi thông tin đăng nhập DB của bạn"), tôi không thể thay đổi thông tin đăng nhập DB, đây là RW và mọi nỗ lực thay đổi chúng (hiện tại) làm hỏng DB máy chủ SQL. Đây không phải là vấn đề của tôi, và tôi không thể xem xét giải quyết vấn đề đó, vì vậy đó là lý do tại sao tôi muốn xem xét việc tạo kết nối DB như nó hoàn toàn, tích cực phải giết mọi .... errr, ý tôi là hoàn toàn, tích cực không thể thay đổi dữ liệu DB.

Cheers

MH

+0

Câu trả lời đầu tiên bạn đã đúng. – RichardOD

+0

Tôi nghĩ trong trường hợp này, bạn không thể thay đổi quyền của thông tin bạn đang sử dụng thực sự là vấn đề của bạn, vì đó sẽ là giải pháp tốt nhất ... –

+0

Đó có thể là "sự cố" của tôi, nhưng hoàn toàn không có gì Tôi có thể làm về nó, thiếu MS để sửa chữa các vấn đề SQL Server miễn phí, ngoài giờ làm việc. Đó là một trong những vấn đề có thể được giải quyết, nhưng có thể không (nó có thể liên quan đến việc tải lại hoàn toàn các hệ thống CNTT chính, đó là một công việc lớn), vì vậy tôi cần phải làm việc với giả thiết rằng nó sẽ không. –

Trả lời

5

Những gì bạn có dưới sự kiểm soát của mình là các lớp học để đạt mã (L2S). Tôi đề nghị ghi đè lên một phần lớp SubmitChanges cho datacontext của bạn để không làm gì (hoặc thậm chí ném một lỗi!) (Hoặc thực hiện tất cả các phương thức mở rộng InsertObject, UpdateObject hoặc DeleteObject thuộc về datacontext của bạn)

+0

Ý tưởng hay, tôi sẽ đặt nó vào và kiểm tra nó - thx. Không tốt bằng cách tạo ra conn RO, nhưng một lớp khác để ngăn chặn bất cứ điều gì, ít nhất. –

6

Không, không có cách nào (mà tôi biết). Thật không may cho bạn, đúng cách để làm điều đó sẽ là thay đổi các khoản tài trợ của người dùng hiện tại hoặc tạo người dùng mới chỉ với các đặc quyền được chọn. Tôi nhận ra đây không phải là câu trả lời bạn đang tìm kiếm nhưng có một máy chủ Sql mà tai nạn khi bạn cố gắng thay đổi mọi thứ trong nó có vẻ là một vấn đề mà thực sự là giá trị xem xét. Có phải vì bạn đang sử dụng tài khoản "sa" để kết nối không? Nếu vậy bạn nên tạo một người dùng khác và cấp quyền thích hợp cho người dùng mới.

+0

Đây không phải là tài khoản sa và đó là SEP (vấn đề của người khác) mà tôi không có thẩm quyền hoặc thẩm quyền. Tôi biết họ đang cố gắng giải quyết vấn đề, nhưng tôi nghĩ đó là vấn đề cơ bản với máy chủ SQL (2008?) Để họ có thể hoặc không thể khắc phục được nó - vì vậy tôi muốn làm cho DB conn RO –

+0

vừa kiểm tra và đó là SQL Server 2005 –

3

Nó thực sự phụ thuộc vào cơ sở dữ liệu và nhà cung cấp DB bạn đang sử dụng. Một số cho phép truy cập chỉ đọc trên chuỗi kết nối, một số thì không.

Ví dụ:

SQL Server 2005 CE, khi sử dụng các nhà cung cấp .NET Compact Framework dữ liệu cho SQL Server Mobile, có một tham số có thể File Mode=Read Only;. (xem trên connectionstrings.com).

SQL Server 2008, doesn't.

Bạn có thể kiểm tra thêm trên connectionstrings.com.

+0

Thx, trang web đó rất hữu ích - đó là máy chủ SQL đầy đủ 2005 nên tôi gắn vào DB thay vì tệp để điều CE không áp dụng, thật không may là –

1

bạn không thể làm gì ở cấp chuỗi kết nối để ngăn việc viết khác hơn là thay đổi người dùng - mà bạn đã nói bạn không thể làm.

Trong trường hợp đó, bạn chỉ cần làm hết sức trong mã của mình để ngăn chặn bất kỳ lần ghi nào; tức là:

  • bất kỳ lớp công cộng nào không được hiển thị cập nhật/xóa/chèn ngữ nghĩa hay bất cứ điều gì.
  • thực hiện bất kỳ lớp lớp dữ liệu kín để họ không thể được overriden

Tuy nhiên, bạn vẫn có gì ngăn cản một lập trình viên từ đến cùng, tách ra khỏi chuỗi kết nối của bạn, và gắn bó nó bên trong kết nối riêng của họ để thực hiện ghi.

Do đó, bạn có thể di chuyển chuỗi kết nối ở một nơi khác mà chỉ có mã nội bộ biết cách truy cập (mặc dù nó sẽ không được sử dụng mã văn bản!); nó vẫn không ngăn bất cứ ai sử dụng nó - nhưng nó làm cho nó khó hơn rất nhiều.

(đã thêm) Tôi nên giải thích lý do tại sao nó không bảo vệ nó. Bỏ qua một bên rằng nguồn gốc của chuỗi kết nối có khả năng truy cập được, ngay cả khi được bảo vệ bằng các thư viện mã hóa vv, không có gì ngăn tôi phản ánh mã của bạn và gọi nó, ngoài các mức tin tưởng. Bạn có thể chọn để đi toàn bộ con đường obfuscation để ngăn chặn tôi từ deconstructing mã của bạn; nhưng chắc chắn mức độ hoang tưởng này là không cần thiết trong nhà phát triển của bạn?

Cuối cùng, bởi vì đó là 'SEP' (vấn đề của người khác) khi bạn đặt nó, và bạn không kiểm soát được điều đó - nếu có ai hỏi bạn tại sao, mặc dù nỗ lực tốt nhất của bạn, bạn không thể bảo đảm không viết sẽ được thực hiện, bạn có thể đổ lỗi một cách an toàn rằng 'ai đó khác'.

Các vấn đề liên quan