एसएलएल स्कीमा तुलना सीएलआर ऑब्जेक्ट स्थापित करने के बाद अपडेट नहीं होगी 'स्रोत स्कीमा बहाव का पता चला'

Question

कस्टम सीएलआर ऑब्जेक्ट स्थापित करने के बाद एसक्यूएल सर्वर डेवलपर टूल्स (एसएसडीटी) वीएस2012 अपडेट की अनुमति नहीं देगा। ।।। त्रुटि स्रोत स्कीमा बहाव का पता चला है "प्रेस ताज़ा करने के लिए की तुलना करने के बाद ताज़ा एक ही बात होता है

की कोशिश की सेटिंग्स में, मैं सिर्फ संग्रहित प्रक्रियाओं के लिए ऑब्जेक्ट सेट सेटिंग्स -।> सामान्य -> ​​संभव डेटा हानि पर ब्लॉक -> चालू और बंद दोनों की कोशिश की

Answer 1

यह एक जवाब है, लेकिन इस समस्या से निपटने के एक सुराग नहीं है

मैं varchar [200] vARCHAR करने के लिए [मैक्स] से एक colum अद्यतन करने के लिए था और इस समस्या को मिला है।। साथ ही। इसलिए मैंने सर्वर में लॉग इन किया और SQL प्रबंधन स्टूडियो के माध्यम से मैन्युअल रूप से डेटाबेस को अद्यतन करने का प्रयास किया जो कि वहां स्थापित किया गया था, और मुझे यह त्रुटि मिली:

"Saving changes is not permitted. The changes you have made require the folloing tables to be drpped and re-created. You have either made changes to a table that can't be re-created or enable the option Prevent saving changes that require the table to be re-created." 

ऐसा लगता है कि तालिका को फिर से बनाना इतना खतरनाक है कि "संभावित डेटा खोने पर ब्लॉक/अनब्लॉक" संभाल नहीं सकता है। तो मुझे लगता है कि अगर हम इस स्थानीय चेतावनी के आसपास चल सकते हैं, तो क्या हम डेटाबेस को दूरस्थ रूप से अपडेट कर सकते हैं।

लेकिन, क्यों [200] [अधिकतम] तालिका फिर से बना रहा है? इसका कोई मतलब नहीं बनता। मैंने [200] [1000] करने की कोशिश की, और यह भी काम नहीं किया। यह इस समस्या की कुंजी हो सकती है।

और, यदि आप SQL प्रबंधन स्टूडियो की बजाय वीएस में सर्वर एक्सप्लोरर में एक ही अद्यतन करते हैं, तो यह काम करता है। फिर, क्यों?

Answer 2

इस प्रकार का लूप भी एक संदर्भित एसएसडीटी परियोजना के निर्माण में असफल होने के कारण हो सकता है। संदर्भित प्रोजेक्ट गायब, अनलोड हो सकता है, या एक त्रुटि हो सकती है जो तुलना को पूरा करने से रोकती है।

Answer 3

मैंने व्यवस्थापक के रूप में वीएस चलाने की कोशिश की, यह काम किया।

Answer 4

ऐसा तब हो सकता है जब एक डीबी उपयोगकर्ता "बदलता" हो।

निम्नलिखित डरावनी फ़ोरम पृष्ठ उन मुद्दों को याद करता है जहां विदेशी हैकर्स "sa" डीबी उपयोगकर्ता तक पहुंच को बलपूर्वक बल देने की कोशिश कर रहे थे, प्रत्येक उपयोगकर्ता के दिनांक टाइमस्टैम्प को बदलने का प्रयास (जिसे स्कीमा बहाव के रूप में देखा जाता है):

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/5c22a7b4-7a82-4717-a118-2475bc62705b/schema-compareupdate-error-target-schema-drift-detected?forum=ssdt

यहाँ यह भी उल्लेख किया है कि आप सा-उपयोगकर्ता कई बार क्वेरी कर सकता है, अगर यह आप के लिए हो रहा है देखने के लिए:

SELECT * FROM sys.server_principals WHERE principal_id=1 

मैं वर्तमान में ही समस्या का सामना कर रहा हूँ (कि sa-user संशोधित किया जा रहा है; मैं अभी तक हैकर्स के बारे में कुछ भी नहीं जानता) और अभी तक कोई समाधान नहीं मिला है। अगर मैं ऐसा मैं इस सवाल का जवाब अपडेट करेंगे।