คำถามติดแท็ก linked-server

เซิร์ฟเวอร์ที่เชื่อมโยงช่วยให้สามารถดำเนินการกับเซิร์ฟเวอร์หลายตัวเป็นแบบสอบถามเดียว

2
ตัวเลือกใดมีประสิทธิภาพมากกว่า: เลือกจากเซิร์ฟเวอร์ที่เชื่อมโยงหรือแทรกลงในเซิร์ฟเวอร์ที่เชื่อมโยง
สมมติว่าฉันต้องส่งออกข้อมูลจากเซิร์ฟเวอร์หนึ่งไปยังเซิร์ฟเวอร์อื่น (ผ่านเซิร์ฟเวอร์ที่เชื่อมโยง) ข้อความใดจะมีประสิทธิภาพมากขึ้น การดำเนินการในเซิร์ฟเวอร์ต้นทาง: INSERT INTO [DestinationLinkedServer].[DestinationDB].[dbo].[Table] SELECT a, b, c, ... FROM [dbo].Udf_GetExportData() หรือดำเนินการในเซิร์ฟเวอร์เป้าหมาย: INSERT INTO [dbo].[Table] SELECT a, b, c, ... FROM OPENQUERY([OriginLinkedServer], 'SELECT a, b, c, ... FROM [OriginDB].[dbo].Udf_GetExportData()') อันไหนจะเร็วกว่าและใช้ทรัพยากรน้อยลง (ทั้งเซิร์ฟเวอร์ต้นทางและเซิร์ฟเวอร์เป้าหมาย) เซิร์ฟเวอร์ทั้งสองเป็น SQL Server 2005

4
การคัดลอกตาราง (หลายร้อย) จากเซิร์ฟเวอร์หนึ่งไปยังอีก (ด้วย SSMS)
ฉันมีตารางหลายร้อย (ปัจจุบัน 466 แต่เคยเติบโต) ตารางฉันต้องคัดลอกจากเซิร์ฟเวอร์หนึ่งไปยังอีก ฉันไม่เคยทำแบบนี้มาก่อนดังนั้นฉันไม่แน่ใจเลยว่าจะเข้าใกล้มันอย่างไร ตารางทั้งหมดอยู่ในรูปแบบเดียวกัน:Cart<Eight character customer number> นี่เป็นส่วนหนึ่งของโครงการขนาดใหญ่ที่ฉันรวมCart<Number>ตารางเหล่านี้ทั้งหมดเข้ากับตารางเดียวCartsแต่นั่นเป็นคำถามที่แตกต่างกันโดยสิ้นเชิง ใครบ้างมีวิธีปฏิบัติที่ดีที่สุดที่ฉันสามารถใช้เพื่อคัดลอกตารางเหล่านี้ทั้งหมดหรือไม่ ชื่อฐานข้อมูลบนเซิร์ฟเวอร์ทั้งสองจะเหมือนกันหากเป็นเช่นนั้น และอย่างที่ฉันบอกไว้ก่อนหน้านี้ฉันมีsaบัญชีเพื่อให้ฉันสามารถทำสิ่งที่จำเป็นเพื่อรับข้อมูลจาก A ถึง B เซิร์ฟเวอร์ทั้งสองอยู่ในเซิร์ฟเวอร์ฟาร์มเดียวกันเช่นกัน

5
เหตุใดการส่งข้อมูลที่ชัดเจนนี้ทำให้เกิดปัญหากับเซิร์ฟเวอร์ที่เชื่อมโยงเท่านั้น
ฉันกำลังสืบค้นข้อมูลจากเซิร์ฟเวอร์ที่เชื่อมโยงผ่านมุมมองบนเซิร์ฟเวอร์ต้นทาง มุมมองต้องรวมคอลัมน์มาตรฐานสองสามมาตรฐานเช่นCreated, ModifiedและDeleted, แต่ในกรณีนี้ตารางบนเซิร์ฟเวอร์ต้นทางไม่มีข้อมูลที่เหมาะสม คอลัมน์จึงถูกส่งไปยังประเภทที่เกี่ยวข้องอย่างชัดเจน ฉันอัปเดตมุมมองเปลี่ยนคอลัมน์จาก NULL AS Modified ไปยัง CAST(NULL as DateTime) as Modified อย่างไรก็ตามหลังจากดำเนินการอัปเดตนี้มุมมองกำลังเรียกใช้ข้อความแสดงข้อผิดพลาดต่อไปนี้: ข่าวสารเกี่ยวกับ 7341 ระดับ 16 สถานะ 2 บรรทัด 3 ไม่สามารถรับค่าแถวปัจจุบันของคอลัมน์ "(นิพจน์ที่ผู้ใช้สร้างขึ้น). Expr1002" จากผู้ให้บริการ OLE DB "SQLNCLI11" สำหรับเซิร์ฟเวอร์ที่เชื่อมโยง "" เราได้ทำ "การแปลงที่ชัดเจน" โดยทั่วไปทั่วเซิร์ฟเวอร์ต้นทางโดยไม่ต้องกังวลและฉันสงสัยว่าปัญหาอาจเกี่ยวข้องกับรุ่นของเซิร์ฟเวอร์ที่เกี่ยวข้อง เราไม่จำเป็นต้องใช้นักแสดงนี้ แต่มันรู้สึกสะอาดขึ้น ตอนนี้ฉันแค่อยากรู้ว่าทำไมสิ่งนี้เกิดขึ้น รุ่นเซิร์ฟเวอร์ (ที่มา): Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 14 พฤษภาคม …

3
Pivot แถวในหลายคอลัมน์
ฉันมีอินสแตนซ์ SQL Server ที่มีเซิร์ฟเวอร์ที่เชื่อมโยงกับเซิร์ฟเวอร์ Oracle มีตารางบนเซิร์ฟเวอร์ Oracle ที่เรียกว่าPersonOptionsซึ่งมีข้อมูลต่อไปนี้: ╔══════════╦══════════╗ ║ PersonID ║ OptionID ║ ╠══════════╬══════════╣ ║ 1 ║ A ║ ║ 1 ║ B ║ ║ 2 ║ C ║ ║ 3 ║ B ║ ║ 4 ║ A ║ ║ 4 ║ C ║ ╚══════════╩══════════╝ ฉันต้องหมุนข้อมูลนั้นเพื่อผลลัพธ์คือ: ╔══════════╦═════════╦══════════╦══════════╗ ║ PersonID …

2
ฉันจะทำให้เซิร์ฟเวอร์ที่เชื่อมโยงทำงานโดยใช้การรับรองความถูกต้อง Windows ได้อย่างไร
ฉันกำลังพยายามนำเซิร์ฟเวอร์ที่เชื่อมโยงไปยัง ServerA ที่สร้างขึ้นบนเซิร์ฟเวอร์อื่นโดยใช้ ServerB "ทำโดยใช้บริบทความปลอดภัยปัจจุบันของการเข้าสู่ระบบ" ในสภาพแวดล้อมของโดเมน ฉันอ่านว่าฉันต้องสร้าง SPN สำหรับบัญชีบริการที่ใช้ SQL Server ในแต่ละเซิร์ฟเวอร์เพื่อเปิดใช้งาน Kerberos ฉันได้ทำไปแล้วและตอนนี้ทั้งสองแสดงรูปแบบการตรวจสอบสิทธิ์เป็น Kerberos อย่างไรก็ตามฉันยังคงพบข้อผิดพลาด: "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'". ใน Active Directory ฉันเห็นว่าบัญชีบริการสำหรับ ServerB เชื่อถือได้สำหรับการมอบหมายให้ MSSQLSvc แต่ฉันสังเกตเห็นว่าบัญชีบริการสำหรับ ServerA ยังไม่ได้เปิดใช้งาน "เชื่อใจผู้ใช้นี้สำหรับการมอบหมาย" เซิร์ฟเวอร์เป้าหมายต้องเปิดใช้งานตัวเลือกนั้นด้วยหรือไม่ มีสิ่งใดอีกที่จำเป็นในการใช้การเข้าสู่ระบบ Windows ปัจจุบันเพื่อใช้เซิร์ฟเวอร์ที่เชื่อมโยงหรือไม่

5
เหตุใดเซิร์ฟเวอร์ที่เชื่อมโยงจึงมีข้อ จำกัด ถึง 10 สาขาในนิพจน์ CASE
ทำไมCASEการแสดงออกนี้: SELECT CASE column WHEN 'a' THEN '1' WHEN 'b' THEN '2' ... c -> i WHEN 'j' THEN '10' WHEN 'k' THEN '11' END [col] FROM LinkedServer.database.dbo.table สร้างผลลัพธ์นี้หรือไม่ ข้อความแสดงข้อผิดพลาด: ข่าวสารเกี่ยวกับ 8180, ระดับ 16, สถานะ 1, คำสั่ง Line 1 ไม่สามารถจัดเตรียมได้ ข่าวสารเกี่ยวกับ 125, ระดับ 15, สถานะ 4, นิพจน์กรณีบรรทัด 1 อาจซ้อนอยู่ในระดับ 10 …

3
จะโหลดเซิร์ฟเวอร์ที่เชื่อมโยงใหม่ได้อย่างไร
ฉันใช้ Microsoft SQL Server 2014 Enterprise Edition ปัญหาเกิดขึ้นกับเซิร์ฟเวอร์ที่เชื่อมโยงซึ่งจำเป็นต้องรีสตาร์ทเซิร์ฟเวอร์หรือเพื่อหยุดMSSQLSERVERบริการ เมื่อเซิร์ฟเวอร์ทำงานอีกครั้งเซิร์ฟเวอร์ที่เชื่อมโยง (กับ DB2) จะทำงานไม่ถูกต้องและ SQL Server แสดงข้อผิดพลาดนี้: ข่าวสารเกี่ยวกับ 7302 ระดับ 16 สถานะ 1 บรรทัด 10 ไม่สามารถสร้างอินสแตนซ์ของผู้ให้บริการ OLE DB "DB2OLEDB" สำหรับเซิร์ฟเวอร์ที่เชื่อมโยง "Airspe" หลังจากรีสตาร์ทเซิร์ฟเวอร์หลายครั้งเซิร์ฟเวอร์ที่เชื่อมโยงจะเริ่มทำงาน เหตุใดจึงจำเป็นต้องรีสตาร์ทเซิร์ฟเวอร์หลาย ๆ ครั้งเพื่อติดตั้งเซิร์ฟเวอร์ที่เชื่อมโยง มีวิธีแก้ไขปัญหาอื่น ๆ อีกไหม? นี่คือสคริปต์เพื่อสร้างหนึ่งในเซิร์ฟเวอร์ที่เชื่อมโยง: EXEC master.dbo.sp_addlinkedserver @server = N'AIRS', @srvproduct=N'Microsoft OLE DB Provider for DB2', @provider=N'DB2OLEDB', @datasrc=N'###.###.###.##',@provstr=N'Provider=DB2OLEDB; …

3
การสร้างเซิร์ฟเวอร์ที่เชื่อมโยงที่ชี้ไปที่ตัวเอง
ฉันพยายามสร้างเซิร์ฟเวอร์ที่เชื่อมโยงกับอินสแตนซ์ SQL Server 2014 servername\instancenameโดยใช้การเรียกต่อไปนี้: EXEC master.dbo.sp_addlinkedserver @server = N'servername\instancename', @srvproduct=N'SQL Server' ฉันได้รับข้อผิดพลาด: Msg 15028, Level 16, State 1, Procedure sp_addlinkedserver, Line 82 The server 'servername\instancename' already exists. นี้ทำงานได้ดีใน SQL Server 2005 และเป็นไปตามMSDN , เซิร์ฟเวอร์ที่เชื่อมโยงไม่จำเป็นต้องเป็นอินสแตนซ์อื่นของ SQL Server ดังนั้นฉันไม่แน่ใจว่ามีอะไรเปลี่ยนแปลงในเวอร์ชันล่าสุดที่ไม่อนุญาตสิ่งนี้ การใช้ UI สร้างข้อความที่คล้ายกัน: คุณไม่สามารถสร้างเซิร์ฟเวอร์ SQL ภายในเครื่องเป็นเซิร์ฟเวอร์ที่มีการเชื่อมโยง ฉันเข้าใจว่ามันเป็นเรื่องแปลกที่จะขอ แต่มันก็เพื่อสนับสนุนรหัสดั้งเดิมที่ทำงานในปี 2005 (และเคยเป็นกรณีที่แยกต่างหาก) เอกสารระบุว่าควรใช้งานได้ แต่ไม่สามารถทำได้ …

5
ข้อผิดพลาดเซิร์ฟเวอร์ที่เชื่อมโยงไม่ถูกจับโดย TRY-CATCH
ฉันกำลังตั้งค่างานเพื่อวนรอบรายการเซิร์ฟเวอร์ที่เชื่อมโยงและดำเนินการแบบสอบถามเฉพาะกับแต่ละรายการ ฉันพยายามที่จะดำเนินการค้นหาภายในบล็อก TRY-CATCH ดังนั้นหากมีปัญหากับเซิร์ฟเวอร์หนึ่งฉันสามารถเข้าสู่ระบบ แต่แล้วดำเนินการกับเซิร์ฟเวอร์อื่น ๆ แบบสอบถามที่ฉันกำลังดำเนินการภายในลูปมีลักษณะดังนี้: BEGIN TRY SELECT * FROM OPENQUERY([server1], 'SELECT 1 AS c;'); END TRY BEGIN CATCH SELECT ERROR_NUMBER(), ERROR_MESSAGE(); END CATCH; PRINT 'We got past the Catch block!'; หากมีปัญหาในการเชื่อมต่อกับเซิร์ฟเวอร์รหัสจะล้มเหลวทันทีและไม่ได้ถ่ายโอนไปยังCATCHบล็อก หากเซิร์ฟเวอร์เชื่อมต่อ แต่มีข้อผิดพลาดในแบบสอบถามจริงเช่นหารด้วยศูนย์จะมีการตรวจจับสิ่งนี้ตามที่คาดไว้โดยCATCHบล็อก ตัวอย่างเช่นฉันสร้างเซิร์ฟเวอร์ที่เชื่อมโยงกับชื่อที่ฉันรู้ว่าไม่มีอยู่ เมื่อดำเนินการข้างต้นฉันเพิ่งได้รับ: OLE DB provider "SQLNCLI" for linked server "nonserver" returned message "Login timeout …

5
ประสิทธิภาพของเซิร์ฟเวอร์ SQL ที่เชื่อมโยงกับเซิร์ฟเวอร์: เหตุใดแบบสอบถามระยะไกลจึงมีราคาแพง
ฉันมีเซิร์ฟเวอร์ฐานข้อมูลสองตัวเชื่อมต่อผ่านเซิร์ฟเวอร์ที่เชื่อมโยง ทั้งสองเป็นฐานข้อมูล SQL Server 2008R2 และการเชื่อมต่อเซิร์ฟเวอร์ที่เชื่อมโยงจะทำผ่านลิงค์ "SQL Server" ปกติโดยใช้บริบทความปลอดภัยของการเข้าสู่ระบบปัจจุบัน เซิร์ฟเวอร์ที่เชื่อมโยงนั้นมีทั้งในดาต้าเซ็นเตอร์เดียวกันดังนั้นการเชื่อมต่อจึงไม่เป็นปัญหา ฉันใช้แบบสอบถามต่อไปนี้เพื่อตรวจสอบว่าค่าของคอลัมน์identifierใดที่พร้อมใช้งานจากระยะไกล แต่ไม่ใช่ภายในเครื่อง SELECT identifier FROM LinkedServer.RemoteDb.schema.[TableName] EXCEPT SELECT DISTINCT identifier FROM LocalDb.schema.[TableName] identifierบนโต๊ะทั้งสองเป็นดัชนีที่ไม่ใช่คลัสเตอร์ในคอลัมน์ ในพื้นที่มีแถว 2.6M แถวจากระยะไกลเพียง 54 แต่เมื่อมองไปที่แผนแบบสอบถาม 70% ของเวลาดำเนินการจะถูกใช้เพื่อ "ประมวลผลแบบสอบถามระยะไกล" นอกจากนี้เมื่อศึกษาแผนคิวรีที่สมบูรณ์จำนวนแถวท้องถิ่นโดยประมาณนั้น1แทน2695380(ซึ่งคือจำนวนแถวโดยประมาณเมื่อเลือกเฉพาะคิวรีที่มาหลังจากนั้นEXCEPT) เมื่อดำเนินการค้นหานี้จะใช้เวลานานแน่นอน มันทำให้ฉันประหลาดใจ: ทำไมถึงเป็นอย่างนี้? การประมาณค่าเป็น "เพียงแค่" ปิดหรือมีการสอบถามระยะไกลบนเซิร์ฟเวอร์ที่เชื่อมโยงที่มีราคาแพงจริงๆ?

3
ความเสี่ยงเซิร์ฟเวอร์ที่เชื่อมโยง
ฉันกำลังใช้คุณสมบัติใหม่ที่ต้องการข้อมูลจากฐานข้อมูลบนเซิร์ฟเวอร์หลายเครื่อง ฉันเพียงต้องการรวมข้อมูลจากเซิร์ฟเวอร์ทั้งหมดเหล่านี้และจัดเรียง ตัวเลือกสองตัวที่อยู่ในใจคือ: ใช้เซิร์ฟเวอร์ที่เชื่อมโยงและเขียนแบบสอบถามอย่างง่ายเพื่อรวมและเรียงลำดับข้อมูลซึ่งจะเรียกใช้จากเซิร์ฟเวอร์หนึ่งและรวบรวมข้อมูลจากเซิร์ฟเวอร์อื่น ใช้แอปพลิเคชันเพื่อรวบรวมข้อมูลจากเซิร์ฟเวอร์ทั้งหมดและส่งกลับไปยัง SQL Server เพื่อเรียงลำดับ (ไม่ต้องการใช้การเรียงลำดับในแอปพลิเคชัน) เราเรียกใช้เซิร์ฟเวอร์ของเราในกลุ่มที่ใช้งาน / ใช้งานอยู่ใน SQL Server 2008 r2 ฐานข้อมูลทั้งหมดมีสิทธิ์เหมือนกันถ้าคุณมีสิทธิ์เข้าถึงฐานข้อมูล / เซิร์ฟเวอร์เดียวคุณมีสิทธิ์ทั้งหมด นี่เป็นแอปพลิเคชั่นหันหน้าสู่สาธารณะ (ซึ่งต้องมีการเข้าสู่ระบบของผู้ใช้) การใช้เซิร์ฟเวอร์ที่เชื่อมโยงมีความเสี่ยงอะไรบ้าง มีข้อบกพร่องด้านความปลอดภัยที่ฉันควรจะเกี่ยวข้องกับ? มีปัญหาใด ๆ ในการใช้งานเซิร์ฟเวอร์ที่เชื่อมโยงในกลุ่มที่ใช้งานอยู่หรือไม่? จะมีปัญหาเรื่องประสิทธิภาพที่สำคัญเมื่อเทียบกับทางเลือกหรือไม่ ดูเหมือนจะมี "buzz" เชิงลบทั่วไปเกี่ยวกับเซิร์ฟเวอร์ที่เชื่อมโยง แต่ฉันไม่สามารถค้นหาสิ่งที่เป็นรูปธรรมที่จะทำให้ฉันเชื่อว่ามีข้อกังวลจริง ๆ

1
ความยาวสูงสุด 8000 อักขระสำหรับ OPENQUERY กับเซิร์ฟเวอร์ที่เชื่อมโยง
ฉันมีคำถามที่ฉันพยายามเรียกใช้OPENQUERYบน SSRS / SQL Server 2014 แต่ฉันได้รับข้อผิดพลาด: สตริงอักขระที่ขึ้นต้นด้วย [... ] ยาวเกินไป ความยาวสูงสุดคือ 8000 มีวิธีแก้ไขข้อ จำกัด นี้ไหม? สำหรับการอ้างอิงฉันพยายามเรียกใช้แบบสอบถามจาก SSRS ผ่านเซิร์ฟเวอร์ MySQL ที่เชื่อมโยง

1
การใช้เซิร์ฟเวอร์ที่เชื่อมโยงกับ OPENQUERY ในโครงการฐานข้อมูล
ฉันมี SQL Server 2008 ที่ใช้ฐานข้อมูลที่ฉันต้องการจะโยนใน TFS ดังนั้นฉันจึงใช้โครงการฐานข้อมูล Visual Studio 2013 ที่ฉันนำเข้าฐานข้อมูล หลังจากแก้ไขข้อผิดพลาดจำนวนมากฉันติดอยู่กับข้อผิดพลาดเดียวที่เหลืออยู่: ในมุมมองหนึ่ง devs ที่ใช้OPENQUERYในการเข้าถึงเซิร์ฟเวอร์ที่เชื่อมโยง ดังนั้นฉันจึงนำเข้า DACPAC ซึ่งมีฐานข้อมูลที่ถูกต้องและเพิ่มเข้าไปในโครงการโดยใช้Add Database Referenceตัวเลือกการอ้างอิงต่อไปนี้ เวอร์ชันสคริปต์เริ่มต้น นี่คือเวอร์ชันที่สั้นกว่าของการสร้างมุมมองดั้งเดิม: CREATE VIEW dbo.vwStatus AS SELECT StatusID, StatusName FROM OPENQUERY(LinkedServer, 'SELECT * FROM [DB].[dbo].tbStatus') AS derivedtbl_1 นำไปสู่ข้อผิดพลาดต่อไปนี้: ข้อผิดพลาด 136 SQL71501: มุมมอง: [dbo]. [vwStatus] มีการอ้างอิงที่ไม่ได้แก้ไขไปยังวัตถุ [LinkedServer] ความพยายามครั้งแรก ดังนั้นฉันจึงพยายามแทรกตัวแปรชื่อเซิร์ฟเวอร์ FROM OPENQUERY($(LinkedServer), …

1
ฉันควรคาดหวังอะไรจากข้อ จำกัด ขนาดใหญ่ของเซิร์ฟเวอร์ SQL ที่เชื่อมโยง
ผลิตภัณฑ์ของเราใช้ Microsoft SQL Server ขณะนี้เรากำลังใช้ฐานข้อมูลสามฐานและปรับใช้กับฐานข้อมูล SQL Server เดียวเสมอ ฐานข้อมูลที่สามคือ OLTP, OLAP และการตรวจสอบ ฐานข้อมูล OLAP มีข้อมูลขาเข้าขนาดใหญ่บน EOD จากทั้ง OLTP และการตรวจสอบโดยใช้การสืบค้นข้ามฐานข้อมูล คำถาม หากเราต้องปรับใช้ฐานข้อมูลทั้งสามนี้ไปยังอินสแตนซ์ Standard Edition สามแยกภายในเซิร์ฟเวอร์จริงและผูกเข้าด้วยกันโดยใช้คุณสมบัติเซิร์ฟเวอร์ที่เชื่อมโยงของ SQL Server: รหัสสมัครจะโปร่งใสแค่ไหน? ฉันควรคาดหวังการเปลี่ยนแปลงมากแค่ไหน? ข้อมูลขาเข้าของ OLAP มีจำนวนแถว 50k-100k, น้ำหนักบรรทุก 200-500MB ต่อ EOD ฉันควรคาดหวังว่าจะมีประสิทธิภาพลดลงเท่าใด สิ่งที่ฉันควรคาดหวังมาก ๆ พื้นหลัง ขณะนี้เรากำลังทอยลูกค้ารายแรกที่มีผู้ใช้มากกว่า 500 คนพร้อมกัน เรากำลังร่างข้อกำหนดเซิร์ฟเวอร์ซึ่งรวมถึง 64 คอร์และ RAM 256GB สำหรับ SQL …

2
ฉันจะเขียน SQL แบบพกพาที่อ้างถึงเซิร์ฟเวอร์ที่เชื่อมโยงได้อย่างไร
ฉันมีขั้นตอนการจัดเก็บที่อ้างอิงถึงเซิร์ฟเวอร์ที่เชื่อมโยง ในหลาย ๆ ที่ตลอดกระบวนการฉันมีบางอย่างดังต่อไปนี้: INSERT INTO [TableName] (...Columns...) SELECT ...Columns... FROM [ServerName\InstanceName].[Catalogue].[dbo].[TableName] WHERE TableNameID = @TableNameID ขั้นตอนนี้มีอยู่ในสภาพแวดล้อมการพัฒนาของฉันสภาพแวดล้อมการทดสอบและสภาพแวดล้อมแบบสด ปัญหาคือแต่ละสำเนาของโพรซีเดอร์นั้นแตกต่างกันอย่างละเอียดเนื่องจากชื่อเซิร์ฟเวอร์แตกต่างกันสำหรับแต่ละสภาพแวดล้อม สิ่งนี้ทำให้การจัดการการปรับใช้การอัปเดตสคริปต์ลำบาก มีวิธีทำให้โพรซีเดอร์แบบพกพาเพื่อให้แต่ละสภาพแวดล้อมสามารถรันเวอร์ชันที่เหมือนกันได้หรือไม่? ถ้าไม่มีอะไรที่ฉันสามารถทำได้เพื่อให้การปรับใช้สคริปต์มีแนวโน้มที่จะเกิดข้อผิดพลาด / ข้อผิดพลาดน้อยลง
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.