🙆🏽 🌇 🐌 MS SQL सर्वर पर संग्रहण परियोजना, 1C 7.7 और SSDT में विकास स्वचालन के साथ एकीकरण 👌 👩🏽‍✈️ 🆒

समय समाप्त हो रहा है और जल्द ही इस विकास के लगभग कुछ भी नहीं बचेगा, लेकिन मेरे पास इसका वर्णन करने के लिए अभी भी समय नहीं था।

यह बड़ी संख्या में शाखाओं और उप-शाखाओं के साथ संघीय स्तर पर एक कंपनी के बारे में होगा। लेकिन, हमेशा की तरह, यह सब एक छोटे स्टोर के साथ बहुत पहले शुरू हुआ था। इन वर्षों में, एक बहुत तेजी से और सहज विकास हुआ, शाखाएं, विभाजन और अन्य कार्यालय दिखाई दिए, और उन दिनों में आईटी बुनियादी ढांचे पर ध्यान नहीं दिया गया और यह भी एक लगातार घटना है। बेशक, किसी भी प्रतिकृति और स्केलिंग के लिए किसी भी रिजर्व के बिना, हर जगह 1C77 का उपयोग किया गया था, इसलिए, आप जानते हैं, अंत में हम इस निष्कर्ष पर पहुंचे कि विद्युत टेप से बंधे टेंटेक के साथ स्प्रैट-फ्रेंकस्टीन उत्पन्न हुआ था - प्रत्येक शाखा में एक स्वायत्त उत्परिवर्ती था जो केंद्रीय आधार के साथ आदान-प्रदान किया गया था "घुटने के उच्च" मोड में, केवल कुछ संदर्भ पुस्तकें, जिनके बिना, ठीक है, यह बिल्कुल भी असंभव था, और बाकी सभी स्वायत्त हैं। कुछ समय के लिए वे केंद्रीय कार्यालय में शाखा अड्डों की प्रतियों (उनमें से दर्जनों!) के साथ संतुष्ट थे, लेकिन उनमें डेटा कई दिनों तक पिछड़ गया था।

हालाँकि, वास्तविकता को अधिक तेज़ी से और लचीले ढंग से जानकारी प्राप्त करने की आवश्यकता है, और इसके साथ कुछ और करने की आवश्यकता है। इस तरह के पैमाने पर एक लेखा प्रणाली से दूसरे में स्थानांतरित करना अभी भी एक दलदल है। इसलिए, एक डेटा वेयरहाउस (डीएक्स) बनाने का निर्णय लिया गया था, जिसमें विभिन्न डेटाबेस से जानकारी प्रवाहित होगी, ताकि बाद में अन्य सेवाओं और क्यूब्स के रूप में विश्लेषणात्मक प्रणाली, एसएसआरएस रिपोर्ट और लीकेज इस सीडी से डेटा प्राप्त कर सकें।

आगे देखते हुए, मैं कहूंगा कि एक नई लेखा प्रणाली में परिवर्तन लगभग हो चुका है और यहाँ वर्णित अधिकांश परियोजना को निकट भविष्य में अनावश्यक रूप से काट दिया जाएगा। क्षमा करें, निश्चित रूप से, लेकिन कुछ भी नहीं किया जा सकता है।

निम्नलिखित एक लंबा लेख है, लेकिन इससे पहले कि आप पढ़ना शुरू करें, मुझे ध्यान दें कि किसी भी मामले में मैं इस फैसले को एक मानक के रूप में पारित नहीं करता हूं, लेकिन शायद किसी को इसमें कुछ उपयोगी मिलेगा।

मैं परियोजना के लिए एक सामान्य दृष्टिकोण के साथ शुरू करूंगा, जिसके लिए एसएसडीटी को विकास के वातावरण के रूप में चुना गया था, जो गिट में परियोजना के बाद के प्रकाशन के साथ था। मुझे लगता है कि आज पर्याप्त विभिन्न लेख और ट्यूटोरियल हैं जो इस उपकरण की ताकत का वर्णन करते हैं। लेकिन कुछ बिंदु ऐसे हैं जिनकी समस्या इस वातावरण के बाहर है।

गणना और डेटाबेस संस्करणों का भंडारण

संस्करण और गणना के बारे में, परियोजना के लिए आवश्यकताओं का मतलब था:

परियोजना के भीतर डेटाबेस संस्करण में परिवर्तन और ट्रैकिंग की सुविधा
प्रवेश के लिए SSMS के माध्यम से डेटाबेस संस्करण देखने की सुविधा
डेटाबेस में संस्करण परिवर्तनों के इतिहास को सहेजना (जो और जब तैनाती की गई)
एक परियोजना में संग्रहित करना
स्थानान्तरण में परिवर्तन और ट्रैकिंग में आसानी
यदि कोई वर्जन संस्करण नहीं था, तो किसी एक के ऊपर डेटाबेस परिनियोजन लॉक
एक नया संस्करण स्थापित करना, रिकॉर्डिंग इतिहास, स्थानांतरण और पुनर्गठन को एक लेनदेन में किया जाना चाहिए और किसी भी स्तर पर विफलता के मामले में पूरी तरह से वापस ले लिया जाना चाहिए।

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

मुझे लगता है कि संस्करण को बढ़ाए बिना तैनाती को अवरुद्ध करने के सभी फायदे स्पष्ट हैं, जिनमें से एक प्रकाशन स्क्रिप्ट को फिर से चलाने में असमर्थता है अगर इसे पहले ही सफलतापूर्वक निष्पादित किया जा चुका है।

यद्यपि डेटाबेस नेटवर्क को अक्सर केवल प्रमुख संस्करण (भिन्न के बिना) का उपयोग करने के लिए प्रस्तावित किया जाता है, हमने XY प्रारूप में संस्करणों का उपयोग करने का निर्णय लिया, जहां वाई पैच है जब टाइपो को तालिका, कॉलम, लिस्टिंग तत्व के नाम, या कुछ और छोटे, के विवरण में सही किया गया था। जैसे कि एक संग्रहीत प्रक्रिया में एक टिप्पणी जोड़ना, आदि। अन्य सभी मामलों में, प्रमुख संस्करण का निर्माण होता है।

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

स्थानान्तरण के साथ, सामान्य तौर पर, सब कुछ सरल है - हम प्रोजेक्ट में एक पोस्टडेप्लो फ़ाइल बनाते हैं और तालिकाओं को अलग करने के लिए इसमें कोड लिखते हैं। मर्ज या ट्रेंकेट्स के साथ - यह है कि आप इसे कैसे पसंद करते हैं। हमने ब्लिंक करना पसंद किया, पूर्व-जाँच करना कि क्या लक्ष्य तालिका में रिकॉर्ड की संख्या स्रोत (परियोजना) में रिकॉर्ड की संख्या से अधिक है। यदि यह अधिक हो जाता है, तो इसका ध्यान आकर्षित करने के लिए एक अपवाद फेंक दिया जाता है, क्योंकि यह अजीब है। स्रोत में कम रिकॉर्ड क्यों हैं? क्योंकि एक अतिश्योक्तिपूर्ण है? अचानक क्यों? और अगर डेटाबेस में पहले से ही लिंक है? यद्यपि हम विदेशी कुंजी (FK) का उपयोग करते हैं, जो आपको रिकॉर्ड को हटाने की अनुमति नहीं देगा, यदि इसके लिंक हैं, तो हम अभी भी इस विकल्प को छोड़ना पसंद करते हैं। नतीजतन, PostDeploy एक अपठनीय शीट में बदल गया, क्योंकि प्रत्येक तालिका को भरने के लिए, मूल्यों के अलावा, एक सत्यापन कोड, एक मर्ज, और भी बहुत कुछ है।

हालाँकि, यदि आप SQLDMD मोड में PostDeploy का उपयोग करते हैं, तो कोड के ब्लॉक को अलग-अलग फ़ाइलों में निकालना संभव हो जाता है, परिणामस्वरूप, PostDeploy में एनुमरेशंस को भरने के लिए फ़ाइल नामों की केवल एक संरचित सूची बनी रहती है।

डेटाबेस संस्करणों के साथ कुछ बारीकियां हैं। डेटाबेस संस्करण को संग्रहीत करने, इसे कैसे दिखना चाहिए और सामान्य रूप से, क्या इसे कहीं संग्रहीत करने की आवश्यकता है, इस बारे में इंटरनेट पर लंबे समय से बहस चल रही है। मान लीजिए कि हम तय करते हैं कि हमें इसकी आवश्यकता है, तो इसे संग्रहीत करने के लिए परियोजना के किस स्थान पर? कहीं पोस्टडेपल स्क्रिप्ट के विल्ड्स में, या इसे एक वैरिएबल में डालें जो स्क्रिप्ट की पहली पंक्ति में घोषित किया गया है?

मेरी राय में, न तो कोई और न ही। जब यह एक अलग फ़ाइल में संग्रहीत होता है तो यह अधिक सुविधाजनक होता है और वहाँ कुछ भी नहीं होता है।

कोई कहेगा - परियोजना के गुणों में dacpac है और आप इसमें संस्करण सेट कर सकते हैं। बेशक, आप इस संस्करण को अपनी स्क्रिप्ट में भी खींच सकते हैं, जैसा कि यहां वर्णित है , लेकिन यह असुविधाजनक है - डेटाबेस संस्करण को बदलने के लिए, आपको कहीं दूर जाने की जरूरत है, बटनों का एक गुच्छा क्लिक करें। मैं Microsoft के तर्क को नहीं समझ पा रहा हूँ - उन्होंने इसे दूर के कोने में छुपा दिया, जैसे कि डेटाबेस पैरामीटर जैसे कि छँटाई, संगतता स्तर, आदि, क्योंकि डेटाबेस संस्करण "अक्सर" के रूप में छँटाई मापदंडों के रूप में बदलता है, है ना? जब निरंतर विकास होता है, तो संस्करण प्रत्येक नई तैनाती के साथ बनता है, ठीक है, ट्रैकिंग परिवर्तन की सुविधा भी एक महत्वपूर्ण भूमिका निभाती है, क्योंकि जब एक अनुकूल नाम के साथ एक बदली हुई फाइल जलाई जाती है, तो यह एक बात है, और जब .sqlproj फ़ाइल को जलाया जाता है, जिसमें XML प्रारूप में कई लाइनें होती हैं। , और उनके बीच कहीं एक पंक्ति के केंद्र में एक परिवर्तित अंक उजागर होता है, किसी तरह बहुत नहीं।

यही बेहतर है

हालाँकि, शायद ये सिर्फ मेरे कॉकरोच हैं और आपको इन पर ध्यान नहीं देना चाहिए।

अब सवाल यह है कि इस संस्करण को पहले से ही तैनात डेटाबेस में कहां संग्रहीत किया जाए। फिर, ऐसा लगता है कि dacpac यह खूबसूरती से करता है - यह सब कुछ सिस्टम प्लेटों पर लिखता है, लेकिन संस्करण को देखने के लिए, आपको अनुरोध को निष्पादित करने की आवश्यकता है (या यह अन्यथा हो सकता है, लेकिन मुझे नहीं पता कि उन्हें कैसे खाना बनाना है? ऐसा लगता है कि SSMS के पुराने संस्करणों में इसके लिए एक इंटरफ़ेस था, और अब कोई)

select * from msdb.dbo.sysdac_instances_internal

व्यवस्थापक के लिए (और न केवल) यह बहुत सुविधाजनक नहीं है। यह बहुत अधिक तार्किक है कि संस्करण को सीधे डेटाबेस के गुणों में प्रदर्शित किया जाएगा।

या नहीं?

ऐसा करने के लिए, आपको उन्नत गुणों का वर्णन करते हुए, प्रोजेक्ट में एक फ़ाइल जोड़ने की आवश्यकता है

 EXECUTE sp_addextendedproperty @name = N'DeployerName', @value = ''; GO EXECUTE sp_addextendedproperty @name = N'DeploymentDate', @value = ''; GO EXECUTE sp_addextendedproperty @name = N'DBVersion', @value = '';

हां, वे खाली हैं, और यह एक प्रकाशन स्क्रिप्ट में बदसूरत दिखता है, लेकिन आप उनके बिना नहीं कर सकते। यदि उन्हें परियोजना में वर्णित नहीं किया गया है, और वे डेटाबेस में होंगे, तो स्टूडियो हर बार उन्हें तैनात करने की कोशिश करेगा। (इस तैनाती के आसपास और अनावश्यक तैनाती विकल्पों के बिना, लेकिन कोई फायदा नहीं हुआ है)

हम PostDeploy स्क्रिप्ट में उनके लिए मान सेट करेंगे।

 declare @username varchar(256) = suser_sname() ,@curdatetime varchar(20) = format(getdate(),'dd.MM.yyyy HH:mm:ss') EXECUTE sp_updateextendedproperty @name = N'DeployerName', @value = @username; EXECUTE sp_updateextendedproperty @name = N'DBVersion', @value = [$(DBVersion)]; EXECUTE sp_updateextendedproperty @name = N'DeploymentDate', @value = @curdatetime;

sp_updateextendedproperty बिना किसी जाँच के sp_updateextendedproperty , क्योंकि जब तक PostDeploy से ब्लॉक शुरू हो गया था, तब तक वे नहीं होने पर सभी गुण पहले ही बन चुके थे।

खैर, इस विषय पर इतिहास रखना अच्छा होगा कि कौन और कब डेटाबेस को तैनात कर रहा है।

उन्नत प्रकाशन विकल्प विंडो में लेन-देन स्क्रिप्ट स्क्रिप्ट बॉक्स को सक्षम करके मानक उपकरण का उपयोग करके लेनदेन में मेटाडेटा परिवर्तनों की तैनाती की जा सकती है। लेकिन यह ध्वज लिपियों (प्री / पोस्ट) को प्रभावित नहीं करता है और ये बिना लेन-देन के चलते रहते हैं। बेशक, कुछ भी पोस्टडेप्लॉय स्क्रिप्ट की शुरुआत में लेनदेन को शुरू करने से रोकता है, लेकिन यह मेटाडेटा से अलग लेनदेन होगा, और पोस्टडेपल में अपवाद होने पर मेटाडेटा परिवर्तन को वापस करने का हमारा काम है।

समाधान सरल है - PreDeploy में लेनदेन शुरू करें, और इसे PostDeploy में करें, और इन उद्देश्यों के लिए प्रकाशन सेटिंग्स में किसी भी चेकमार्क का उपयोग न करें।

प्रोजेक्ट में डेटाबेस संस्करण को सुविधाजनक रूप से संग्रहीत करने और तैनाती के दौरान वांछित स्थानों में इसे पंजीकृत करने के लिए, आप SQLCMD टेबल्स का सहारा ले सकते हैं। हालाँकि, मैं कोड के विकलों में संस्करण को कहीं संग्रहीत नहीं करना चाहता, मैं चाहता हूं कि यह सतह पर हो।

डेटाबेस संस्करण को एक अलग फ़ाइल में रखने के लिए और परियोजना स्तर पर वहाँ से संस्करण का प्रबंधन करने के लिए, हम निम्न ब्लॉक को .sqlproj में जोड़ते हैं:

  <Target Name="BeforeBuild"> <ReadLinesFromFile File="$(ProjectDir)\Properties\DBVersion"> <Output TaskParameter="Lines" PropertyName="ExtDBVersion" /> </ReadLinesFromFile> <WriteLinesToFile File="$(ProjectDir)\\SetPreDepVarsTmp.sql" Lines=":setvar DBVersion $(ExtDBVersion)" Overwrite="true" /> </Target> </Target>

यह MSBuild के लिए निर्देश है कि वह निर्माण से पहले एक फ़ाइल से एक पंक्ति को पढ़ें और रीड डेटा के आधार पर एक अस्थायी फ़ाइल बनाएँ। MSBuild एक अस्थायी फ़ाइल SetPreDepVarsTmp.sql , जो पंक्ति :setvar DBVersion $(ExtDBVersion) , जहाँ $(ExtDBVersion) हमारे संस्करण से पढ़ा गया मान है जो डेटाबेस के संस्करण को संग्रहीत करता है।

इस तरह की जोड़तोड़ के बाद, आप इस अस्थायी फ़ाइल को PreDeploy स्क्रिप्ट से संदर्भित कर सकते हैं और इसमें वैश्विक लेनदेन शुरू कर सकते हैं:

 :r .\SetPreDepVarsTmp.sql go :r ".\BeginTransaction.sql"

मध्यवर्ती संस्करण

प्रारंभ में, ExtendedProperties.sql फ़ाइल को खाली मान नहीं दिया गया था, लेकिन चर से मान

 EXECUTE sp_addextendedproperty @name = N'DeployerName', @value = [$(DeployerName)]; GO EXECUTE sp_addextendedproperty @name = N'DeploymentDate', @value = [$(DeploymentDate)]; GO EXECUTE sp_addextendedproperty @name = N'DBVersion', @value = [$(DBVersion)];

चर, बदले में, MSPuild द्वारा SetPreDepVarsTmp.sql फ़ाइल में स्वचालित रूप से पंजीकृत किए गए थे:

  <PropertyGroup> <CurrentDateTime>$([System.DateTime]::Now.ToString(dd.MM.yyyy HH:mm:ss))</CurrentDateTime> </PropertyGroup> <PropertyGroup> <NewLine> -- </NewLine> </PropertyGroup> <Target Name="BeforeBuild"> <ReadLinesFromFile File="$(ProjectDir)\DBVersion"> <Output TaskParameter="Lines" PropertyName="ExtDBVersion" /> </ReadLinesFromFile> <WriteLinesToFile File="$(ProjectDir)\SetPreDepVarsTmp.sql" Lines=":setvar DBVersion $(ExtDBVersion)$(NewLine):setvar DeploymentDate "$(CurrentDateTime)"$(NewLine):setvar DeploymentUser $(UserDomain)\$(UserName)" Overwrite="true" /> </Target>

इस दृष्टिकोण के साथ, आपको PostDeploy में इन संपत्तियों को फिर से स्थापित करने की आवश्यकता नहीं है, लेकिन परेशानी यह है कि SetPreDepVarsTmp.sql में स्थिर मूल्य शामिल हैं और यदि प्रकाशन स्क्रिप्ट अभी उत्पन्न हुई थी, लेकिन एक घंटे में तैनात की गई, या इससे भी बदतर, अगले दिन (डेवलपर ने इसे लंबे समय तक जांचा। नेत्रहीन, उदाहरण के लिए), गुणों में निर्दिष्ट प्रकाशन तिथि वास्तविक प्रकाशन तिथि से भिन्न होगी और इतिहास में तारीख के साथ मेल नहीं खाती।

BeginTransaction.sql फ़ाइल सामग्री

संक्षेप में, यह मानक लेनदेन प्रारंभ ब्लॉक से सिर्फ कॉपी-पेस्ट है जिसे स्टूडियो तब उत्पन्न करता है जब लेनदेन स्क्रिप्ट सक्षम करें चेक बॉक्स चयनित होता है , लेकिन हम इसे अपने तरीके से उपयोग करते हैं। स्क्रिप्ट में, केवल अस्थायी तालिका नाम को #tmpErrors से बदलकर #tmpErrors कर दिया #tmpErrorsManual ताकि कोई नाम संघर्ष न हो अगर कोई चेकबॉक्स चालू करता है।

 IF (SELECT OBJECT_ID('tempdb..#tmpErrors')) IS NOT NULL DROP TABLE #tmpErrorsManual GO CREATE TABLE #tmpErrorsManual (Error int) GO SET XACT_ABORT ON GO SET TRANSACTION ISOLATION LEVEL READ COMMITTED GO BEGIN TRANSACTION GO

PostDeploy स्क्रिप्ट

 declare @TableName VarChar(255) = null --        if $(SkipEnumDeploy) = 0 begin PRINT N' ...' :r ..\\EnumTable1.sql end --   PRINT N'  ...'; declare @username varchar(256) = suser_sname() , @curdatetime varchar(20) = format(getdate(),'dd.MM.yyyy HH:mm:ss') if $(DBVersion) > (select isnull( MAX( DBVersion),0) from zDBVersionHistory) begin insert into zDBVersionHistory( DBVersion, DeploymentDate, DeployerName) values ($(DBVersion),@curdatetime,@username) EXECUTE sp_updateextendedproperty @name = N'DeployerName', @value = @username; EXECUTE sp_updateextendedproperty @name = N'DBVersion', @value = [$(DBVersion)]; EXECUTE sp_updateextendedproperty @name = N'DeploymentDate', @value = @curdatetime; end else begin RaisError ( N':          ,  .      ,        DBVersion          .' , 16 , 1 ) WITH SETERROR; end GO :r ".\CaptureTransactionError.sql" :r ".\CommitTransaction.sql"

SkipEnumDeploy वैरिएबल, जैसा कि यह पहले से ही स्पष्ट हो गया है, आपको अपडेटिंग लिस्टिंग के चरण को छोड़ने की अनुमति देता है, यह मामूली कॉस्मेटिक परिवर्तनों के लिए उपयोगी हो सकता है। हालांकि, धर्म के दृष्टिकोण से, यह सच नहीं हो सकता है, हालांकि, विकास के स्तर पर यह निश्चित रूप से उपयोगी है।

CaptureTransactionError.sql और CaptureTransactionError.sql फ़ाइलें भी मानक लेन-देन एल्गोरिथ्म से कॉपी पेस्ट (मामूली बदलाव के साथ) हैं जो स्टूडियो उपरोक्त झंडे के सेट होने पर उत्पन्न करता है, और जिसे हम अब अपने दम पर खेलते हैं।

विषय-वस्तु

 IF @@ERROR <> 0 AND @@TRANCOUNT > 0 BEGIN ROLLBACK; END IF @@TRANCOUNT = 0 BEGIN INSERT INTO #tmpErrorsManual (Error) VALUES (1); BEGIN TRANSACTION; END

कमिटेशन। Sql सामग्री

 IF EXISTS (SELECT * FROM #tmpErrorsManual) ROLLBACK TRANSACTION GO DROP TABLE #tmpErrorsManual GO IF @@TRANCOUNT>0 BEGIN PRINT N'     .' COMMIT TRANSACTION END ELSE RaisError ( N'    .' , 16 , 1 );

सामग्री EnumTable1.sql

 set @TableName = N'Table1' PRINT N'  '+@TableName+'...' begin try set nocount on drop table if exists #tmpEnums; select * into #tmpEnums from (values ( 0, ' 1') , ( 1, ' 2') , ( 2, ' 3') ) as tmp ( Id , Title ) set nocount off --         If ((select count(*) from Table1) > (select count(*) from #tmpEnums)) begin RaisError ( N':      ,   .' , 0 , 1 ) WITH SETERROR; end set Identity_insert Table1 on Merge Table1 as target Using ( select * from #tmpEnums except select * from dbo.Table1 ) as source on target.Id = source.Id when matched then update set target.Title = source.Title when not matched by target then insert ( Id , Title ) values ( source.Id , source.Title ); set Identity_insert Table1 off drop table if exists #tmpEnums; END TRY begin catch IF @@trancount > 0 ROLLBACK TRANSACTION set @Error_Message = Error_Message(); RaisError ( N': %s.' , 0 , 1 , @Error_Message ) WITH SETERROR; end catch :r "..\\CaptureTransactionError.sql"

Publish स्क्रिप्ट में निम्न संरचना होगी

 -- PreDeploy ----:setvar DBVersion "10.6" --   ,     DBVersion ----   --    ,           -- PostDeploy ----  ----   ----

आदर्श रूप से, निश्चित रूप से, मैं चाहूंगा कि प्रकाशन के समय संस्करण प्रदर्शित किया जाए

लेकिन आप इस विंडो में फ़ाइल से मान नहीं खींच सकते हैं, हालांकि MSBuild इसे पढ़ता है और इसे .DBqproj फ़ाइल में अतिरिक्त निर्देशों की मदद से एक्सटीडी वर्जन संपत्ति में डालता है, जैसा कि ऊपर दिए गए उदाहरण में है, लेकिन निर्माण

  <SqlCmdVariable Include="DBVersion"> <DefaultValue> </DefaultValue> <Value>$(ExtDBVersion)</Value> </SqlCmdVariable>

लुढ़कता नहीं है।

अपनी वेब डायरी में सिक्वल डेवलपर्स लिखते हैं कि यह कैसे किया जाता है। उनके संस्करण के अनुसार, जादू SqlCommandVariableOverride निर्देश में निहित है, जो सरल है - .sqlproj परियोजना फ़ाइल में कुछ पंक्तियाँ जोड़ें।

 <ItemGroup> <SqlCommandVariableOverride Include="DBVersion=$(ExtDBVersion)" /> </ItemGroup>

और किया। अच्छा प्रयास है, लेकिन नहीं। हो सकता है जब यह ब्लॉग पोस्ट प्रकाशित हुआ था, सब कुछ काम किया था, लेकिन तब से इन अमेरिका में आप तीन राष्ट्रपति चुनाव हुए हैं और किसी को नहीं पता कि निर्देश कल काम करना बंद कर सकते हैं।

और यहाँ एक कॉमरेड ने सभी विकल्पों की कोशिश की, लेकिन उनमें से किसी ने भी नहीं लिया।

इसलिए, या तो dacpac से संस्करण लें, या इसे PostDeploy में संग्रहीत करें, या एक अलग फ़ाइल में, या _________ (अपना संस्करण दर्ज करें)।

1 सी के साथ एकीकरण

पहली समस्या यह थी कि 1C77 के पास कोई एप्लिकेशन सर्वर या अन्य डेमॉन नहीं है जो इसे प्लेटफॉर्म लॉन्च किए बिना इसके साथ बातचीत करने की अनुमति देता है। 1C77 के साथ काम करने वालों को पता है कि उसके पास पूर्ण कंसोल मोड नहीं है। आप प्लेटफ़ॉर्म को मापदंडों के साथ चला सकते हैं और यहां तक कि उनके आधार पर कुछ भी कर सकते हैं, लेकिन बहुत कम कंसोल पैरामीटर हैं और उनका उद्देश्य अलग था। लेकिन यहां तक कि उनकी मदद से, आप एक पूरे संयोजन को नाकाम कर सकते हैं। हालांकि, यह अप्रत्याशित रूप से उड़ सकता है, यह एक मोडल विंडो को बाहर ला सकता है और किसी को ओके और अन्य आकर्षण पर क्लिक करने के लिए इंतजार कर सकता है। और, शायद, सबसे बड़ी समस्या - प्लेटफ़ॉर्म की गति वांछित होने के लिए बहुत कुछ छोड़ देती है ... इसलिए, 1 सी डेटाबेस में केवल एक ही समाधान है - प्रत्यक्ष प्रश्न। संरचना को देखते हुए, आप केवल इन प्रश्नों को नहीं ले सकते और लिख सकते हैं, लेकिन लाभ यह है कि एक संपूर्ण समुदाय है कि एक समय में एक अद्भुत उपकरण विकसित किया गया है - 1 सी ++ (1cpp.dll), जो उनके लिए अविश्वसनीय है! पुस्तकालय आपको 1 सी के संदर्भ में प्रश्न लिखने की अनुमति देता है, जो तब तालिकाओं और क्षेत्रों के वास्तविक नामों में बदल जाता है। यदि किसी को पता नहीं है, तो एक छद्म नाम का उपयोग करके अनुरोध लिखा जा सकता है और यह इस तरह दिखेगा

 select  from $.

ऐसा अनुरोध मनुष्यों के लिए समझ में आता है, लेकिन सर्वर पर ऐसी कोई तालिका और फ़ील्ड नहीं है, अन्य नाम हैं, इसलिए 1C ++ इसे में बदल देगा

 select SP5278 from SC2235

और ऐसा अनुरोध सर्वर द्वारा पहले से ही समझा जाता है। हर कोई खुश है, कोई भी शपथ नहीं लेता है - न तो एक व्यक्ति, न ही एक सर्वर। यहाँ, ऐसा लगता है, इस मुद्दे को हल कर दिया गया है।

दूसरी समस्या कॉन्फ़िगरेशन के विमान में है: एक कॉन्फ़िगरेशन का उपयोग शाखाओं में, दूसरे में केंद्रीय कार्यालय में और तीसरे में शाखाओं में किया गया था! कक्षा !! 1 मुझे भी ऐसा लगता है। इसके अलावा, वे विशिष्ट नहीं हैं और यहां तक कि विशिष्ट विरासत भी नहीं है, लेकिन वाइकिंग्स के दौरान खरोंच से पूरी तरह से लिखा गया है और, दुर्भाग्य से, सबसे अच्छे आर्किटेक्ट ने इन कॉन्फ़िगरेशन की नींव नहीं रखी ... उदाहरण के लिए, कार्यान्वयन दस्तावेज़ में प्रत्येक कॉन्फ़िगरेशन में विवरण का एक अलग सेट है। लेकिन न केवल कुछ क्षेत्रों के नाम अलग-अलग होते हैं, जो विवरण के नामों के समान होने पर बहुत अधिक मजेदार होते हैं, लेकिन उनमें संग्रहीत डेटा का अर्थ अलग-अलग होता है।

कॉन्फ़िगरेशन में लगभग कोई रजिस्टरों का उपयोग नहीं किया जाता है, सब कुछ दस्तावेजों की पेचीदगियों पर बनाया गया है। इसलिए, कभी-कभी मुझे कॉन्फ़िगरेशन से कुछ प्रक्रिया के तर्क को दोहराने के लिए, मामलों के एक समूह के साथ एक साफ लेनदेन पर एक पूरी शीट लिखनी होती थी, जो प्रपत्र पर पाठ क्षेत्र में कुछ जानकारी प्रदर्शित करता है।

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

हम अनुरोधों की कहानी जारी रखते हैं। जाहिर है, डेटा निष्कर्षण के लिए सभी ब्लॉक स्टोरेज में बदल गए ताकि बाद में उन्हें 1C प्लेटफॉर्म को दरकिनार करके सर्वर साइड पर लॉन्च किया जा सके। नियम यह था: एक भंडारण एक इकाई को पुनः प्राप्त करने के लिए जिम्मेदार है। क्योंकि शुरुआती चरण में विशलिस्ट पहले से ही बहुत अधिक जमा हो गया है, क्योंकि यह वर्षों से दर्दनाक हो गया है, फिर दर्जनों भंडारण फाइलें निकल गई हैं।

तीसरी समस्या यह है कि विकास की गति और गुणवत्ता कैसे बढ़ाई जाए, और फिर इस सभी राक्षस का समर्थन कैसे किया जाए? 1 सी ++ के लिए एक अनुरोध लिखें और भंडारण में इसके रूपांतरण के परिणाम को कॉपी-पेस्ट करें? यह बहुत असुविधाजनक और थकाऊ है, इसके अलावा, त्रुटियों की एक उच्च संभावना है - गलत एक या गलत को कॉपी करें या क्वेरी की अंतिम पंक्ति का चयन न करें और इसके बिना कॉपी करें। यह विशेष रूप से सच है जब यह 1C प्रश्नों को निर्देशित करने के लिए आता है, क्योंकि इसमें निर्देशिका की तरह कोई छद्म नाम नहीं है । नामकरण। अनुच्छेद, केवल वास्तविक नाम SC2235.SP5278 और इसलिए सामानों की निर्देशिका के तहत एक अनुरोध को कॉपी करना जो ग्राहकों को पुनर्प्राप्त करता है, बहुत सरल है। बेशक, अनुरोध सबसे अधिक संभावना है कि गंतव्य तालिका में प्रकार और फ़ील्ड्स की संख्या के बेमेल होने के कारण गिरावट आएगी, लेकिन समान प्लेट्स हैं, जैसे कि गणना, जहां केवल दो कॉलम आईडी और नाम हैं। सामान्य तौर पर, यह केवल किसी प्रकार के स्वचालन को लागू करने के लिए रहता है। खैर, पर्याप्त गीत, चलो व्यापार के लिए नीचे उतरो!

मैं चाहता था कि भंडारण विकास प्रक्रिया कुछ इस तरह से घटे:

हम छद्म नामों के साथ SQL क्वेरी को ठीक करते हैं और इसे सहेजते हैं
हम एक मैजिक बटन दबाते हैं और बाहर निकलने पर हमें परिवर्तित SQL पर सही संग्रहीत कार्यविधि प्राप्त होती है, जो सर्वर के लिए स्पष्ट है

कुछ विवरण

तीसरी समस्या को हल करने के लिए, बाहरी प्रसंस्करण (.ert) लिखा गया था। प्रसंस्करण में कई प्रक्रियाएँ होती हैं, जिनमें से प्रत्येक में छद्म नाम का उपयोग करके एक इकाई निकालने के लिए क्वेरी पाठ होता है, जैसे कि

 select * from $.

प्रसंस्करण फॉर्म पर, एक विशेष प्रक्रिया के परिणाम को प्रदर्शित करने के लिए एक क्षेत्र है, अर्थात। अनुरोध एक ऐसे रूप में परिवर्तित हो जाता है जो सर्वर के लिए समझ में आता है ताकि आप इसे जल्दी से आज़मा सकें। इसके अलावा, डिबग ब्लॉक को हमेशा इस अनुरोध में जोड़ा जाता है, चर की घोषणा के साथ, परीक्षण डेटाबेस, सर्वर और अधिक के नाम। यह केवल SSMS में कॉपी-पेस्ट करने और F5 दबाने के लिए ही रहता है। आप निश्चित रूप से इस अनुरोध को प्रसंस्करण से ही निष्पादित कर सकते हैं, लेकिन अनुरोध योजना और यह सब, ठीक है, आप समझते हैं ... सामान्य तौर पर, यह कैसे डिबगिंग किया जाता है। क्योंकि कई कॉन्फ़िगरेशन हैं; प्रसंस्करण में, अलग-अलग कॉन्फ़िगरेशन के लिए समान क्वेरीज़ को ऑब्जेक्ट्स के छद्म नामों से अंतिम प्रश्नों में परिवर्तित करना संभव है। वास्तव में, एक कन्फ़ेक्शन में नामकरण संदर्भ SC123 है, और दूसरे में - SC321। लेकिन 1C ++ आपको रनटाइम में अलग-अलग कॉन्फ़िगरेशन लोड करने और उनमें से प्रत्येक के लिए एक व्यक्तिगत आउटपुट उत्पन्न करने की अनुमति देता है।

इसके बाद, बैच रन मोड को प्रोसेसिंग में जोड़ा गया, जब यह प्रत्येक कॉन्फ़िगरेशन के लिए स्वचालित रूप से प्रत्येक प्रक्रिया शुरू करता है, और उनमें से प्रत्येक का उत्पादन .sql फ़ाइलों (इसके बाद मूल फ़ाइलों) के लिए लिखा जाता है। इस प्रकार, हमें मूल फ़ाइलों के संयोजन का एक गुच्छा मिलता है, जिसे बाद में वीएस का उपयोग करके स्वचालित रूप से संग्रहीत प्रक्रियाओं में बदलना चाहिए। यह ध्यान देने योग्य है कि आधार फ़ाइलों में डिबग ब्लॉक शामिल है ।

ऐसा लगता है, क्यों संग्रहीत प्रक्रियाओं की अंतिम फ़ाइलों के लिए तुरंत निष्कर्ष नहीं बनाते हैं और इस प्रसंस्करण में सब कुछ रखते हैं? तथ्य यह है कि कुछ परीक्षणों के लिए, प्रश्नों के डिबग संस्करणों को उन बैचों में चलाना आवश्यक है जिनमें सभी चर घोषित किए गए हैं, साथ ही मैं चाहता था कि संग्रहीत प्रक्रिया के नाम वीएस से प्रबंधित किए जाएं, 1 सी को दरकिनार करते हुए, क्योंकि यह तर्कसंगत है, है न?

वैसे, परियोजना में मूल फाइलें भी संग्रहीत की जाती हैं, ठीक है, निश्चित रूप से तैयार संग्रहीत प्रक्रियाओं की फाइलें। किसी भी समय, 1C शुरू किए बिना, आप SSMS में आधार फ़ाइल खोल सकते हैं और इसे चर घोषणाओं से परेशान किए बिना निष्पादित कर सकते हैं।

प्रसंस्करण में, अनुरोध वाली सभी प्रक्रियाएं भी टेम्प्लेट होती हैं, जिसमें समान मापदंडों का सेट होता है, लेकिन इस या उस प्रक्रिया में केवल आवश्यक पैरामीटर का उपयोग किया जाता है। कुछ में, सब कुछ शामिल है, और कुछ में, दो पर्याप्त हैं। इसलिए, टेम्पलेट को कॉपी करने और खुद को प्रश्नों के साथ मापदंडों में भरने के लिए एक नई प्रक्रिया को जोड़ना आता है।

प्रसंस्करण प्रक्रियाओं में से एक का कोड, जो बाद में एक संग्रहीत प्रक्रिया में बदल जाएगा

अंतिम क्वेरी कुछ इस प्रकार है:

 ++"("+OPENQUERY()+")"+

प्रसंस्करण की उपस्थिति

कॉन्फ़िगरेशन स्विच करते समय, डेटा सूची में आइटम को उतारने के लिए उपलब्ध (आवश्यक) आइटमों की सूची बदल जाती है। यदि संभव हो तो, 1 सी में प्रक्रिया कोड जितना संभव हो उतना एकीकृत था। यदि समकक्षों को निकाला जाता है और ये निर्देशिका अलग-अलग कॉन्फ़िगरेशन में असंगत हैं, तो पीढ़ी प्रक्रिया के अंदर अलग-अलग मामले हैं, जैसे: यह ब्लॉक सभी के लिए तय किया गया है, यह एक ऐसे कॉन्फॉन के लिए केवल अंतिम अनुरोध में जोड़ा जाता है, और दूसरे के लिए एक है। यह पता चला है कि एक इकाई के लिए संग्रहीत प्रक्रियाओं में लेकिन विभिन्न विन्यास वे न केवल तालिका के नाम से भिन्न हो सकते हैं, बल्कि एक में मौजूद जोड़ के पूरे ब्लॉक और दूसरे में अनुपस्थित हैं। आउटपुट फ़ील्ड्स का सेट, निश्चित रूप से एक ही है और रिसीवर टेबल या एसएसआईएस पैकेज के कंटेनर से मेल खाता है, कुछ फ़ील्ड कॉन्फ़िगरेशन के लिए स्टब्स से भरा हुआ है जिसमें ये विवरण सिद्धांत रूप में नहीं हैं।

मैजिक बटन

विजुअल स्टूडियो में MSbuild और भयानक T4 टेम्पलेट जैसे उपकरण हैं। इसलिए, एक जादुई बटन के रूप में, T4 के लिए C # में एक स्क्रिप्ट लिखी गई थी, जो:

रजिस्ट्री में एक खाली कॉन्फ़िगरेशन पंजीकृत करता है (अन्यथा 1C एक मान दर्ज करने के लिए सुझाव के साथ एक मोडल विंडो प्रदर्शित करेगा और उपयोगकर्ता कार्यों के लिए प्रतीक्षा करेगा)
SQL सर्वर पर इस konf के लिए एक खाली डेटाबेस बनाता है, क्योंकि इसके बिना 1C एक त्रुटि देगा
1C लॉन्च करता है और OLE के माध्यम से प्रोसेसिंग (एक ही .ert) को निष्पादित करने के लिए कहता है, 1C के लिए एक अद्वितीय GUID भी स्थानांतरित करता है।
आउटपुट तैयार-निर्मित (परिवर्तित) अनुरोधों और एक मार्कर फ़ाइल के साथ फ़ाइलों की एक श्रृंखला है, जिसमें स्टार्टअप पर प्राप्त GUID लिखा गया है
रजिस्ट्री से मान का पंजीकरण हटा दिया जाता है और सर्वर से एक अस्थायी खाली डेटाबेस हटा दिया जाता है
टोकन फ़ाइल की सामग्री की जाँच करता है। यदि मार्कर फ़ाइल में GUID है जिसे हमने 1C में पारित किया था जब यह शुरू हुआ था, इसका मतलब है कि यह अंत तक काम करता है, दुर्घटनाग्रस्त नहीं हुआ, आदि, फिर अगले चरण पर जाएं, या हम एक त्रुटि प्रदर्शित करते हैं
हम स्टोरेज बनाते हैं।
हम मॉड्यूल ग्रंथों और प्रसंस्करण रूपों को प्राप्त करने के लिए gcomp के साथ .ert फ़ाइल को विघटित करते हैं, ठीक है, हम बाद में गिट को भेजने और इसे सही ढंग से प्रदर्शित करने के लिए, यूनिकोड में परिवर्तित करते हैं। उन लोगों के लिए जो 1 सी के साथ काम नहीं करते थे: .ert फ़ाइल एक बाइनरी और स्टूडियो है, साथ में गिट, यह मानता है कि .ert फ़ाइल को बदल दिया गया है, लेकिन यह स्पष्ट नहीं है कि वास्तव में इसमें क्या बदलाव आया है, शायद बस किसी ने बटन को अपने पिक्सेल को बाईं ओर ले जाया (जो बिना औचित्य के अस्वीकार्य)

T4 , ( , ) . , . , , , , - — 1.

, , , , , . — 1, 1, - .

: ?

/ ;
VS , ;
4;
. हो गया।

क्योंकि , , .sqlproj,

 <ItemGroup> <None Include=" \1.sql"> <None Include=" \2.sql"> <None Include=" \3.sql"> </ItemGroup>

 <ItemGroup> <Content Include=" \*.sql" /> </ItemGroup>

« ». , , , :)

, , (, ) . ( ), , - - - , .

, . . , , , , , ( ), . , ( , ) , , , . , . , , , , , ( , 1, , MD ).

, OPENQUERY , 1 , , , , EXEC . OPENQUERY , , , .

177 ( ) SQL2000, varchar(max) , varchar(8000), 9, … , EXEC(@SQL1+@SQL2). , SQL2016, SQL2000. , , .

 select ... from ( select ... from @1CDBName.dbo.$. join @1CDBName.dbo.$. join ... where xxx = 'hello!' ^--       8 , ,        ,       ,   .          ,             .. ... join ... ) join ...

 CREATE PROCEDURE [dbo].[SP1] @LinkedServerName varchar(24) ,@1CDBName varchar(24) AS BEGIN Declare @TSQL0 varchar(8000), @TSQL1 varchar(8000), @TSQL2 varchar(8000) set @TSQL0=' select ... from OPENQUERY('+@LinkedName+','' select ... from '+@1CDBName+'.dbo.DH123. join '+@1CDBName+'.SC123. ... where '; set @TSQL1=' xxx = ''''hello!'''' join ... join ... )'' join ... '''; set @TSQL2=' ... EXEC(@TSQL0+@TSQL1+@TSQL2) END

— . (, ) , , , , , , OPENQUERY 8 .

.ert , .. , .

, .

ETL

, ( ). (Stage). , ETL SSIS , , , , . . ( ), .

, ( ) , , (.. ), , .

, , . , . zabbix.

.

क्योंकि 1 , , . , , truncate .

, ( ) -, « 1-» .

SSIS

,

SSIS SQL Server (SQL Server Destination), , OLE DB (OLE DB Destination).

, , , . , , . (, )

. , , , (/ ).
.

, ( ). यानी , . , , . - — . .

, (.. ) .

, , .

पुनश्च

, , , , . — , . - , , .

MS SQL सर्वर पर संग्रहण परियोजना, 1C 7.7 और SSDT में विकास स्वचालन के साथ एकीकरण

गणना और डेटाबेस संस्करणों का भंडारण

1 सी के साथ एकीकरण

कुछ विवरण

ETL

,

पुनश्च

More articles: