5

के आधार पर अलग-अलग स्क्रिप्ट बनाएं, जिस समस्या को मैं हल करना चाहता हूं वह बिल्ड कॉन्फ़िगरेशन के आधार पर अलग-अलग स्क्रिप्ट बनाना है।एसक्यूएल डाटाबेस प्रोजेक्ट: निर्माण कॉन्फ़िगरेशन

हम एसक्यूएल सर्वर के दो उदाहरणों है कहते हैं: जुड़े लिंक्ड सर्वर साथ

  • एंटरप्राइज संस्करण ऑफ़लाइन विकसित करने और इकाई के लिए
  • LocalDb संस्करण का परीक्षण करती है

एंटरप्राइज संस्करण लिंक्ड सर्वर जब के लिए दृश्य दिखाई देते हैं स्थानीय डीबी स्थानीय टेबल के साथ उन विचारों को प्रतिस्थापित करता है।

उन लिंक किए गए सर्वर दृश्य और स्थानीय तालिकाओं में समान नाम और फ़ील्ड सेट हैं। इसलिए वे डिफ़ॉल्ट रूप से निर्माण में शामिल नहीं हैं (बिल्ड एक्शन = कोई नहीं)। इसके बजाय वे प्रोजेक्ट फ़ाइल के पहलेबिल्ड लक्ष्य में निर्माण में शामिल हैं।

<Target Name="BeforeBuild"> 

    <ItemGroup Condition=" '$(Configuration)' == 'LocalDb'"> 
     <Build Include="Local_Tables\*.sql" /> 
    </ItemGroup> 

    <ItemGroup Condition=" '$(Configuration)' != 'LocalDb' "> 
     <Build Include="Linked_Server_Views\*.sql" /> 
    </ItemGroup> 

</Target> 

लेकिन समस्या यह दृश्य स्टूडियो कैश कि डीबी मॉडल और अगर हम पहले LocalDb के लिए परियोजना का निर्माण और उसके बाद उद्यम विन्यास के लिए परियोजना का निर्माण करने की कोशिश है - दृश्य स्टूडियो आउटपुट त्रुटियों:

त्रुटि: SQL71508: मॉडल में पहले से ही एक तत्व है जिसमें एक ही नाम है

अगर समाधान बंद करें और खोलें या अनलोड प्रोजेक्ट और रीलोड प्रोजेक्ट को खोलें, तो विजुअल स्टूडियो डीबीएमडीएल फाइलों को पुन: प्रयास करता है और एंटरप्राइज़ कॉन्फ़िगरेशन त्रुटियों के बिना बनाया जा रहा है।

तो मेरी धारणा है कि अगर मैं डीबीएमडीएल कैश रीफ्रेश करता हूं तो मुझे बिना त्रुटि के चिकनी निर्माण मिल जाएगा।


जब आप खुले या फिर से लोड SQL सर्वर डाटाबेस परियोजना दृश्य स्टूडियो 2012 में, यह विस्तार dbmdl है, जो एक deserialized और कैश की गई db मॉडल है के रूप में वर्णित here वाली फ़ाइल बनाता है।

dbmdl फ़ाइल मनोरंजन विजुअल स्टूडियो के पल में निम्नलिखित आउटपुट:

Deserializing the project state for project 'MyProject.sqlproj'... 
Detecting file changes for project 'MyProject.sqlproj'... 
Deserialization has been completed for project 'MyProject.sqlproj'. 

कैसे परियोजना को फिर से लोड के बिना और इस परियोजना xml फ़ाइल के बदले बिना dbmdl कैश ताज़ा करने के लिए दृश्य स्टूडियो के लिए मजबूर करने?

क्या डीबीएमडीएल कैश को प्रोजेक्ट xml फ़ाइल के पहलेबिल्ड या आफ्टरबिल्ड लक्ष्य में कमांड रखने का कोई तरीका है?

या समस्या का पूरा दृष्टिकोण गलत है और निर्माण कॉन्फ़िगरेशन के आधार पर अलग-अलग स्क्रिप्ट बनाने का एक और तरीका है?

उत्तर

4

आपके पास समग्र परियोजनाओं का उपयोग करने में एक और संभावित विकल्प हो सकता है। जेमी थॉम्पसन ने उनके बारे में यहां ब्लॉग किया: http://sqlblog.com/blogs/jamie_thomson/archive/2013/03/10/deployment-of-client-specific-database-code-using-ssdt.aspx

यह आपको एक मुख्य परियोजना बनाने और पर्यावरण-विशिष्ट कोड के साथ अतिरिक्त परियोजनाओं में टाई करने देगा। आप रिलीज स्क्रिप्ट में कुछ चेक करके उपयुक्त एक को तैनात कर सकते हैं।

1

मैं इस बारे में सोच रहा था और एसएसडीटी के साथ इसे संभालने का सबसे अच्छा तरीका था। मैं शायद आप अपने परिवर्तन प्रकाशित करने से पहले सही संस्करण निर्धारित कर सकते हैं एक "सर्वश्रेष्ठ" जिस तरह से, लेकिन की जरूरत नहीं है, मैं इस पर विचार करेंगे:

  1. एक प्रत्येक संस्करण के लिए प्रोफ़ाइल को प्रकाशित बनाएँ - साथ और लिंक किए गए सर्वर के बिना।
  2. अपने लिंक किए गए सर्वर नामों को पकड़ने के लिए चर बनाएं, संभवतः डेटाबेस सहित "[सर्वर]।[डेटाबेस]। "
  3. अपने लिंक किए गए सर्वर दृश्यों के लिए एक पोस्ट-तैनाती स्क्रिप्ट बनाएं। इसमें अनुमतियां, लिंक किए गए सर्वर नामों के चर, और इसी तरह शामिल होना चाहिए।
  4. पोस्ट-तैनाती स्क्रिप्ट में, अपने" संस्करण "परिवर्तनीय। यदि यह लिंक किए गए सर्वर का उपयोग करेगा, तो लिंक किए गए सर्वर पर किसी का उपयोग करने के लिए प्रोजेक्ट में मूल गैर-लिंक किए गए सर्वर दृश्यों को ड्रॉप/पुन: बनाएँ। वैकल्पिक रूप से, स्थानीय दृश्य और सर्वर के लिए चर को एक खाली स्ट्रिंग पर सेट करें/डीबी लिंक किए गए सर्वर के लिए और आप शायद कोड के एक सेट का उपयोग कर सकते हैं।

यह आपके विचारों को कोड-जांच करने में सक्षम नहीं होने का नुकसान है, लेकिन आपको उन लिंक किए गए सर्वर दृश्यों को स्टोर करने के लिए एक स्थान देगा और एक पीएलएसी ई से उन्हें तैनात करने के लिए। एसएसडीटी को बदलावों को संभालने की बजाय आपको ड्रॉप/बिल्ड के साथ रिलीज करने की आवश्यकता होगी जिसका अर्थ है कि उन्हें प्रत्येक प्रकाशित कार्रवाई पर फिर से बनाया जाएगा। मुझे लगता है कि यह आपको वह समाधान दे सकता है जो आप चाहते हैं।

+0

पीटर आपके उत्तर के लिए धन्यवाद। मेरे पास अभी भी मेरे प्रश्न का कोई समाधान नहीं है। मैं अगली परियोजना के लिए आपकी सलाह का प्रयास करूंगा। लेकिन मुझे लगता है कि पोस्ट-डिप्लॉय स्क्रिप्ट के लिए टेबल/व्यू सृजन के निर्माण को स्थानांतरित करने से हमें बिल्डिंग के दौरान त्रुटि मिलती है, क्योंकि अन्य ऑब्जेक्ट्स उन टेबल/दृश्यों को संदर्भित करते हैं। –

+1

ठीक है, आप तकनीकी रूप से अपने प्रोजेक्ट के लिए "स्थानीय" दृश्यों में छोड़ सकते हैं, इसलिए सब कुछ बन जाएगा, फिर एक पोस्ट-तैनाती अनुभाग जोड़ें जो उन्हें लिंक किए गए सर्वर के विरुद्ध चलाने के लिए केवल तभी बदलता है जब आप उनका उपयोग करेंगे। मैं मानता हूं कि इसे संभालने का यह सबसे अच्छा तरीका नहीं है, लेकिन अगर आप इसे इस तरह से करते हैं तो इसे काम करना चाहिए। –

+1

आपके पास समग्र परियोजनाओं का उपयोग करने में एक और संभावित विकल्प हो सकता है। जेमी थॉम्पसन ने यहां उनके बारे में ब्लॉग किया: http://sqlblog.com/blogs/jamie_thomson/archive/2013/03/10/deployment-of-client-specific-डेटा-code-using-ssdt.aspx –