پاسخ به پرسش‌ها
ساخت یک دیتابیس ترکیبی از SQL و فایل های XML

۱: راهکار بهینه، نیاز به دیتای بیشتری داره، چون مثلا سایز تیم تولید، دانش و امکانات نگهداری سیستم بعد از راه‌اندازی، زیرساخت و امکانات سخت‌افزاری و... می‌تونه پاسخ نهایی رو کلی تغییر بده.

۲: ۱۰۰۰ کالا از ۱۰۰ سایت، آیا دامنه تغییر این اعداد مثلا ۱۲۰۰ کالا از ۱۳۰ سایت خواهد بود؟ یا امکانش هست که در کوتاه/میان‌مدت تبدیل به ۱۰٬۰۰۰ کالا از ۵۰۰۰ سایت بشه؟ (پیش‌بینی رشد)

۳: ایندکس‌گذاری روی XML در SQL Server به خوبی پشتیبانی می‌شه، سایز XML در سریالایز/دیسریالایز شدن و طبیعتن در کارایی سیستم اثرگذار است

۴: برای محصولی مثل SQL Server نگهداری ۴۰ میلیون رکورد (۱ سال داده‌ با اعدادی که فرمودید) عدد کوچکی است، «ولی» بسیار وابسته به اینه که زیرساخت خوب و مدیردیتابیس با دانشی داشته باشید وگرنه حتی ۴۰۰٬۰۰۰ رکورد هم می‌تونه مشکل ایجاد کنه

۵: این نوع سیستم‌ها عموما در مرحله جمع‌آوری به صورت OLTP طراحی می‌شن و برای سابقه به DW با ساختار Dimensional تبدیل و منتقل می‌شن. باز هم بستگی به تیم و شرایط تولید داره

۶: نکته بعدی اینکه مثلا به راحتی می‌تونید دیتا رو روی جدول پارتیشن‌بندی کنید و پارتیشن‌های قدیمی رو فشرده کنید

مطالب
استفاده‌ی گسترده از DateTimeOffset در NET Core.
اگر به سورس‌های ASP.NET Identity نگارش‌های 2 و 3 دقت کنیم، این تفاوت به وضوح قابل مشاهده‌است:
در نگارش 2
public virtual DateTime? LockoutEndDateUtc { get; set; }
در نگارش 3
public virtual DateTimeOffset? LockoutEnd { get; set; }
و در کل، در طراحی تمام قسمت‌ها و اجزای NET Core. بجای استفاده‌ی از DateTime متداول، شاهد استفاده‌ی گسترده‌ای از DateTimeOffset هستیم که از زمان ارائه‌ی NET 3.5. معرفی شده‌است. چرا؟


مشکل ساختار DateTime چیست؟

تمام کسانیکه مدتی با NET Framework. کار کرده‌اند، قطعا از ساختار DateTime برای ذخیره سازی اطلاعاتی زمانی محلی استفاده کرد‌ه‌اند. اما مشکل DateTime چیست؟
فرض کنید در حال استفاده‌ی از یک وب سرویس قرار گرفته‌ی در یک منطقه‌ی زمانی غربی هستید و این وب سرویس تاریخ تولد افراد را با یک چنین فرمتی ارائه می‌دهد:
 2012-03-01 00:00:00-05:00
در این حالت برای استفاده‌ی متداول از این زمان می‌توان به صورت زیر عمل کرد:
 var dateString = "2012-03-01 00:00:00-05:00";
var birthDay = DateTime.Parse(dateString);
هرچند این عملیات ساده به نظر می‌رسد، اما با توجه به قرارگیری سرور برنامه در یک منطقه‌ی زمانی دیگر، زمان پردازش شده به صورت ذیل خواهد بود:
 2012-02-29 11:00:00 PM
اتفاقی که رخ داده‌است، تبدیل DateTime رسیده به زمان محلی سرور است و در این حالت تاریخ تولد شخص از یکم ماه، به 29 ام ماه قبل تغییر کرده‌است. علت آن هم وجود 05:00 یا offset (فاصله‌ی با UTC) در تاریخ ارائه شده‌است.
چگونه می‌توان offset را در تاریخ ذکر کرد، اما از تبدیل آن به زمان محلی جلوگیری کرد؟ این مورد جایی‌است که ساختار DateTimeOffset بکار خواهد آمد.


DateTimeOffset و ذخیره‌ی DateTime به همراه Offset

ساختار کلی DateTimeOffset بسیار واضح بوده و تشکیل شده‌است از Date + Time + Offset. اهمیت آن نیز به ذخیره سازی اطلاعات منطقه‌ی زمانی، در قسمت Offset ساختار ارائه شده بر می‌گردد. ساختار DateTimeOffset در بسیاری از موارد با DateTime متداول یکسان است و تفاوت‌های آن شامل خواص اضافی ذیل هستند:
- DateTime: قسمت DateTime مقدار را بدون توجه به offset باز می‌گرداند (به زمان محلی تبدیل نخواهد شد).
- LocalDateTime: قسمت DateTime را با توجه به منطقه زمانی سروری که برنامه بر روی آن اجرا می‌شود، بر می‌گرداند.
- Offset: فاصله‌ی زمانی با UTC را بیان می‌کند. یک TimeSpan است که فاصله‌ی با UTC را بیان می‌کند.
- UtcDateTime: قسمت DateTime را با توجه به UTC time ارائه می‌کند.

در این ساختار خواص Now و UtcNow نیز یک DateTimeOffset را باز می‌گردانند.


چه زمانی از DateTime و چه زمانی از DateTimeOffset استفاده کنیم؟

اگر هدف شما ذخیره سازی اطلاعات زمانی محلی (جایی که سرور برنامه قرار دارد) است، از DateTime استفاده کنید. اما اگر می‌خواهید مقادیر زمانی را در مناطق زمانی دیگری نیز مورد استفاده قرار دهید و علاقمندید که قسمت TimeZone این اطلاعات نیز حفظ شود، از DateTimeOffset استفاده نمائید.

در این حالت روش پردازش صحیح مثال ابتدای بحث به صورت ذیل خواهد بود:
 string birthDay = "2012-03-01 00:00:00-05:00";
var dtOffset = DateTimeOffset.Parse(birthDay);
و در اینجا اگر علاقمند به مقایسه‌ی این مقدار با یک زمان محلی هستیم، می‌توان از خاصیت Date آن استفاده کرد:
 var theDay = dtOffset.Date;
مطابق توصیه‌ی تیم BCL، استفاده از DateTimeOffset روش ترجیح داده شده‌ی برای ذخیره سازی اطلاعات اکثر سناریوهای زمانی است.


SQL Server و پشتیبانی از DateTimeOffset

ساختار داده‌ای datetime در SQL Server نیز اطلاعات منطقه‌ی زمانی را ذخیره نمی‌کند و درصورت بازیابی آن در برنامه، این زمان، به زمان محلی تبدیل خواهد شد. برای رفع این مشکل، از زمان ارائه‌ی SQL Server 2008، ساختار DateTimeOffset نیز به نوع‌های داده‌آی SQL Server اضافه شده‌است:


این ساختار، اطلاعات +00:00 timezone را نیز ذخیره می‌کند.


مشکلات نوع datetime در بانک‌های اطلاعاتی برای ذخیره سازی اطلاعات UTC در آن‌ها

یکی از روش‌های توصیه شده‌ی جهت ذخیره سازی اطلاعات زمانی در بانک‌های اطلاعاتی، استفاد‌ه‌ی از DateTime.UtcNow است. اما زمانیکه از DateTime.UtcNow برای ذخیره سازی اطلاعاتی زمانی استفاده می‌کنیم، به معنای دریافت زمان محلی بر اساس و نسبت به UTC است. در این حالت هنگامیکه آن‌را از یک فیلد datetime بانک اطلاعاتی بازیابی می‌کنیم، از نوع Unspecified خواهد بود (DateTimeKind.Unspecified) و به صورت خودکار به DateTimeKind.Local ترجمه می‌شود. یعنی مقدار آن مجددا به زمان محلی شیفت پیدا خواهد کرد چون نوع datetime بانک اطلاعاتی درکی از DateTimeKind و منطقه‌ی زمانی ندارد.
به همین جهت روش بازیابی صحیح این زمان UTC، نیاز به قید صریح DateTimeKind.Utc را خواهد داشت:
public static class SqlDataReaderExtensions
{
   public static DateTime GetDateTimeUtc(this SqlDataReader reader, string name)
   {
      int fieldOrdinal = reader.GetOrdinal(name);
      DateTime unspecified = reader.GetDateTime(fieldOrdinal);
      return DateTime.SpecifyKind(unspecified, DateTimeKind.Utc);
   }
}
اما اگر نوع فیلد را DateTimeOffset قرار دهیم و از DateTimeOffset.UTCNow برای ذخیره سازی اطلاعات زمانی استفاده کنیم، SqlDataReader بدون نیاز به تبدیلات فوق، قادر است اطلاعات آن‌را به نحو صحیحی دریافت و پردازش کند.


خلاصه‌ی بحث

اگر برنامه‌ی وب شما امروز در یک سرور در اروپا هاست می‌شود و سال بعد در یک سرور کانادایی، استفاده‌ی DateTime.UtcNow کمک زیادی به برنامه نکرده و خروجی SQL Server در این حالت DateTimeKind.Unspecified است و این زمان مجددا بر اساس محل سرور جدید و تنظیمات منطقه‌ی زمانی آن، به حالت DateTimeKind.Local شیفت داده می‌شود که الزاما خروجی صحیحی را به همراه نخواهد داشت و یا اگر قرار است از وب سرویس شما در مناطق زمانی مختلفی استفاده کنند نیز DateTime.UtcNow انتخاب مناسبی نیست. جهت درج فاصله‌ی صحیح با UTC و ذخیره سازی آن در بانک اطلاعاتی، روش توصیه شده، استفاده از نوع DateTimeOffset است و در این حالت دیگر SQL Server اطلاعات را با فرمت زمانی Unspecified بازگشت نمی‌دهد و در سمت کلاینت نیازی به تبدیلات خاصی نخواهد بود.
نظرات مطالب
بررسی خطاهای ممکن در حین راه اندازی اولیه برنامه‌های ASP.NET Core در IIS
- IIS APPPOOL\TestAppPool به عنوان یک User برای SQL Server تعریف شده و دسترسی کامل به دیتابیس مورد نظر براش قرار داده شده!
- همچنین Query دریافت اطلاعات جدول که لاگ میشود بدون مشکل در سرور اجرا می‌شود و در واقع اسکیمای بانک اطلاعاتی با دستور SQL مورد نظر یکی است!
نظرات مطالب
EF Code First #3
- در متن فوق قسمت ششم توضیح داده شده: «اگر علاقمند نیستید که primary key شما از نوع identity باشد، می‌توانید از گزینه DatabaseGeneratedOption.None استفاده نمائید»
- ضمنا این روش کار نیست برای انتقال اطلاعات. اگر از sql server 2008 استفاده می‌کنید، امکان تهیه خروجی به صورت اسکریپت را دارد. یکی از نکاتی که در این اسکریپت لحاظ می‌شود، دو دستور IDENTITY_INSERT  زیر است که با SQL CE هم کار می‌کند:
SET IDENTITY_INSERT [table1] ON;
GO
INSERT INTO [table1] ([Id],...) VALUES (1,...);
GO
SET IDENTITY_INSERT [table1] OFF;
GO
برای اجرای اسکریپت نهایی می‌تونید از sql ce toolbox استفاده کنید.

مطالب
مدیریت کار تیمی با SQL Server

پس از انتشار جزوه‌ی SVN در حدود دو سال قبل، ایمیل در این مورد زیاد داشتم. یکی از سؤالات هم این بود که: "چگونه از SVN جهت مدیریت نگارش‌های مختلف یک بانک اطلاعاتی اس کیوال سرور در یک تیم استفاده کنیم؟ (منظور مدیریت schema است)" و من هم پاسخ مناسبی برای این مورد نداشتم چون کلاینت‌های SVN حداقل با Management studio یکپارچه نمی‌شود (بر خلاف ابزارهای موجود برای VS.NET مانند VisualSVN ، AnkhSVN و غیره). صد البته می‌شود از آن همانند اعمال نگارش به یک فایل Text معمولی مانند فایل‌های SQL استفاده کرد، اما خوب ...

و خبر خوب اینکه شرکت معظم RedGate چند روز قبل یک کتاب رایگان را در این مورد منتشر کرده است:



سرفصل‌های این کتاب
Chapter 1: Writing Readable SQL
Chapter 2: Documenting your Database
Chapter 3: Change Management and Source Control
Chapter 4: Managing Deployments
Chapter 5: Testing Databases
Chapter 6: Reusing T-SQL Code
Chapter 7: Maintaining a Code Library
Chapter 8: Exploring your Database Schema
Chapter 9: Searching DDL and Build Scripts
Chapter 10: Automating CRUD
Chapter 11: SQL Refactoring

دریافت

مطالب
مدیریت اطلاعات وابسته به زمان در بانک‌های اطلاعاتی رابطه‌ای
در یک برنامه فروشگاه، جداول مشتری و خریدهای او را درنظر بگیرید. خرید 3 سال قبل مشتری خاصی به آدرس قبلی او ارسال شده‌است. خرید امروز او به آدرس جدید او ارسال خواهد شد. سؤال: آیا با وارد کردن و به روز رسانی آدرس جدید مشتری، باید سابقه اطلاعاتی قبلی او حذف شود؟ اجناس ارسالی پیشین او، واقعا به آدرس دیگری ارسال شده‌اند و نه به آدرس جدید او. چگونه باید اینگونه اطلاعاتی را که در طول زمان تغییر می‌کنند، در بانک‌های اطلاعاتی رابطه‌ای نرمال شده مدیریت کرد؟ از این نمونه‌ها در دنیای کاری واقعی بسیارند. برای مثال قیمت اجناس نیز چنین وضعی را دارند. یک بستنی مگنوم، سال قبل 300 تومان بود؛ امسال شده است 1500 تومان. یک سطل ماست 2500 تومان بود؛ امروز همان سطل ماست 6500 تومان است. چطور باید سابقه فروش این اجناس را نگهداری کرد؟


منابع مطالعاتی مرتبط

این موضوع اینقدر مهم است که تابحال چندین کتاب در مورد آن تالیف شده است:

Temporal Data & the Relational Model
Trees and Hierarchies in SQL
Developing Time-Oriented Database Applications in SQL
Temporal Data: Time and Relational Databases
Temporal Database Entries for the Springer Encyclopedia of Database Systems
Temporal Database Management

نکته مهمی که در این مآخذ وجود دارند، واژه کلیدی «Temporal data » است که می‌تواند در جستجوهای اینترنتی بسیار مفید واقع شود.


بررسی ابعاد زمان

فرض کنید کارمندی را استخدام کرده‌اید که ساعتی 2000 تومان از ابتدای فروردین ماه حقوق دریافت می‌کند. حقوق این شخص از ابتدای مهرماه قرار است به ساعتی 2400 تومان افزایش یابد. اگر مامور مالیات در بهمن ماه در مورد حقوق این شخص سؤال پرسید، ما چه پاسخی را باید ارائه دهیم؟ قطعا در بهمن ماه عنوان می‌کنیم که حقوقش ساعتی 2400 تومان است؛ اما واقعیت این است که این عدد از ابتدای استخدام او ثابت نبوده است و باید تاریخچه تغییرات آن، در نحوه محاسبه مالیات سال جاری لحاظ شود.
بنابراین در مدل سازی این سیستم به دو زمان نیاز داریم:
الف) actual time یا زمان رخ دادن واقعه‌ای. برای مثال حقوق شخصی در تاریخ ابتدای مهر ماه تغییر کرده است. به این تاریخ در منابع مختلف Valid time نیز گفته می‌شود.
ب) record time یا زمان ثبت یک واقعه؛ مثلا زمان پرداخت حقوق. به آن Transaction time هم گفته شده است.
یک مثال:
 record date  actual date  حقوق دریافتی
1392/01/01  1392/01/01  2000/روز
1392/02/01  1392/01/01  2000/روز
...
1392/07/01  1392/07/01  2400/روز
...
1392/17/01  1392/07/01  2400/روز
در این لیست، ریز حقوق پرداختی به یک شخص را ملاحظه می‌کنید. actual dateها، زمان‌هایی هستند که حقوق پایه شخص در آن‌ها تغییر کرده و record dateها زمان‌هایی هستند که به شخص حقوق داده شده‌است.
به ترکیب Valid Time  و  Transaction Time، اصطلاحا Bitemporal data می‌گویند.


مشکلات طراحی‌های متداول اطلاعات وابسته به زمان

در طراحی‌های متداول، عموما یک جدول کارمندان وجود دارد و یک جدول لیست حقوق‌های پرداختی. رکوردهای لیست حقوق‌های پرداختی نیز توسط یک کلید خارجی به اطلاعات هر کارمند متصل است؛ از این جهت که نمی‌خواهیم اطلاعاتی تکراری را در جدول لیست حقوقی ثبت کنیم و طراحی نرمال سازی شده‌ای مدنظر می‌باشد.
خوب؛ اول مهرماه حقوق شخصی تغییر کرده است. بنابراین کارمند بخش مالی اطلاعات شخص را به روز می‌کند. با این کار، کل سابقه حقوق‌های پرداختی شخص نیز از بین خواهد رفت. چون وجود این کلید خارجی به معنای استفاده از آخرین اطلاعات به روز شده یک کارمند در جدول لیست حقوقی است. الان اگر از جدول لیست حقوقی گزارش بگیریم، کارمندان همواره از آخرین حقوق به روز شده خودشان استفاده خواهند کرد.


راه حل‌های متفاوت مدل سازی اطلاعات وابسته به زمان
برای رفع این مشکل مهم، راه حل‌های متفاوتی وجود دارند که در ادامه آن‌ها را بررسی خواهیم کرد.

الف) نگهداری اطلاعات وابسته به زمان در جداول نهایی مرتبط
اگر حقوق پایه شخص در زمان‌های مختلف تغییر می‌کند، بهتر است عدد نهایی این حقوق پرداختی نیز در یک فیلد مشخص، در همان جدول لیست حقوقی ثبت شود. این مورد به معنای داشتن «داده‌ای تکراری» نیست. از این جهت که داده‌ای تکراری است که اطلاعات آن در تمام زمان‌ها، دارای یک مقدار و مفهوم باشد و اطلاعات حقوق یک شخص اینچنین نیست.

ب) نگهداری اطلاعات تغییرات حقوقی در یک جداول جداگانه
یک جدول ثانویه حقوق جاری کارمندان مرتبط با جدول اصلی کارمندان باید ایجاد شود. در این جدول هر رکورد آن باید دارای بازه زمانی (valid_start_time و valid_end_time) مشخصی باشد. مثلا از تاریخ X تا تاریخ Y، حقوق کارمند شماره 11 ، 2000 تومان در ساعت بوده است. از تاریخ H تا تاریخ Z اطلاعات دیگری ثبت خواهند شد. به این ترتیب با گزارشگیری از جدول لیست حقو‌ق‌های پرداخت شده، سابقه گذشته اشخاص محو نشده و هر رکورد بر اساس قرارگیری در یک بازه زمانی ثبت شده در جدول ثانویه حقوق جاری کارمندان تفسیر می‌شود.
در این حالت باید دقت داشت که بازه‌های زمانی تعریف شده، با هم تداخل نکنند و برنامه ثبت کننده اطلاعات باید این مساله را به ازای هر کارمند کنترل کند و یا با ثبت record_date، اجازه ثبت بازه‌های تکراری را نیز بدهد (توضیحات در قسمت بعد).
به این جدول، یک Temporal table نیز گفته می‌شود. نمونه دیگر آن، نگهداری قیمت یک کالا است از یک تاریخ تا تاریخی مشخص. به این ترتیب می‌توان کوئری گرفت که بستنی مگنوم فروخته شده در ماه آبان سال قبل، بر مبنای قیمت آن زمان، دقیقا چقدر فروش کرده است و نه اینکه صرفا بر اساس آخرین قیمت روز این کالا گزارشگیری کنیم که در این حالت اطلاعات نهایی استخراج شده صحیح نیستند.
حال اگر به این طراحی در جدولی دیگر Transaction time یا زمان ثبت یک رکورد یا زمان ثبت یک فروش را هم اضافه کنیم، به جداول حاصل Bitemporal Tables می‌گویند.


مدیریت به روز رسانی‌ها در جداول Temporal
در جداول Temporal، حذف فیزیکی اطلاعات مطلقا ممنوع است؛ چون سابقه سیستم را تخریب می‌کند. اگر اطلاعاتی در این جداول دیگر معتبر نیست باید تنها تاریخ پایان دوره آن به روز شوند یا یک رکورد جدید بر اساس بازه‌ای جدید ثبت گردد.
همچنین به روز رسانی‌ها در این جداول نیز معادل هستند با یک Insert جدید به همراه فیلد record_date و نه به روز رسانی واقعی یک رکورد قبلی  (شبیه به سیستم‌های حسابداری باید عمل کرد).
یک مثال:
فرض کنید حقوق کارمندی که مثال زده شد، در مهرماه به ساعتی 2400 تومان افزایش یافته است و حقوق نهایی نیز پرداخته شده است. بعد از یک ماه مشخص می‌شود که مدیر عامل سیستم گفته بوده است که ساعتی 2500 تومان و نه ساعتی 2400 تومان! (از این نوع مسایل در دنیای واقعی زیاد رخ می‌دهند!) خوب؛ اکنون چه باید کرد؟ آیا باید رفت و رکورد ساعتی 2400 تومان را به روز کرد؟ خیر. چون سابقه پرداخت واقعی صورت گرفته را تخریب می‌کند. به روز رسانی شما ابدا به این معنا نخواهد بود که دریافتی واقعی شخص در آن تاریخ خاص، ساعتی 2500 بوده است.
بنابراین در جداول Temporal، تنها «تغییرات افزودنی» مجاز هستند و این تغییرات همواره به عنوان آخرین رکورد جدول ثبت می‌شوند. به این ترتیب می‌توان اصطلاحا «مابه التفاوت» حقوق پرداخت نشده را به شخص خاصی، محاسبه و پرداخت کرد (می‌دانیم در یک بازه زمانی خاص به او چقد حقوق داده‌ایم. همچنین می‌دانیم که این بازه در یک record_date دیگر لغو و با عددی دیگر، جایگزین شده‌است).


برای مطالعه بیشتر
Bitemporal Database Table Design - The Basics
Temporal Data Techniques in SQL
Database Design: A Point in Time Architecture
Temporal database
Temporal Patterns



راه حلی دیگر؛ استفاده از بانک‌های اطلاعاتی NoSQL
بانک‌های اطلاعاتی NoSQL برخلاف بانک‌های اطلاعاتی رابطه‌ای برای اعمال Read بهینه سازی می‌شوند و نه برای Write. در چند دهه قبل که بانک‌های اطلاعاتی رابطه‌ای پدیدار شدند، یک سخت دیسک 10 مگابایتی حدود 4000 دلار قیمت داشته است. به همین جهت مباحث نرمال سازی اطلاعات و ذخیره نکردن اطلاعات تکراری تا این حد در این نوع بانک‌های اطلاعاتی مهم بوده است. اما در بانک‌های اطلاعاتی NoSQL امروزی، اگر قرار است فیش حقوقی شخصی ثبت شود، می‌توان کل اطلاعات جاری او را یکجا داخل یک سند ثبت کرد (از اطلاعات شخص در آن تاریخ تا اطلاعات تمام اجزای فیش حقوقی در قالب یک شیء تو در توی JSON). به همین جهت بسیار سریع هستند برای اعمال Read و گزارشگیری. همچنین این نوع سیستم‌ها برای نگهداری نگارش‌های مختلف یک سند بهینه سازی شده‌اند و جزو ساختار توکار آن‌ها است. بنابراین در این نوع سیستم‌ها اگر نیاز است از یک سند خاصی گزارش بگیریم، دقیقا اطلاعات همان تاریخ خاص را دارا است و اگر اطلاعات پایه سیستم را به روز کنیم، از امروز به بعد در سندهای جدید ثبت خواهد شد. این نوع سیستم‌ها رابطه‌ای نیستند و بسیاری از مباحث نرمال سازی اطلاعات در آن‌ها ضرورتی ندارد. قرار است یک فیش حقوقی شخص را نمایش دهیم؟ خوب، چرا تمام اطلاعات مورد نیاز او را در قالب یک شیء JSON تو در توی حاضر و آماده نداشته باشیم؟
مطالب
از کار افتادن SQL Server Agent
SQL Server Agent مربوط به SQL Server 2008 از کار افتاده بود و راه اندازی نمی‌شد. خطای مرتبط با آن در لاگ‌های ویندوز به نحو زیر بود:
 SQLServerAgent could not be started (reason: Unable to connect to server '(local)'; SQLServerAgent cannot start).
پس از مدتی جستجو، عنوان شده بود که مسیر رجیستری زیر را یافته:
 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.MSSQLSERVER\SQLServerAgent
و در آن ServerHost را به نام سرور ویرایش کنید. سپس سرور را ری استارت نمائید. این تغییر انجام شد اما باز هم SQL Server Agent راه اندازی نمی‌شد.
لاگ‌های آن در مسیر ذیل ثبت می‌شوند:
 C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log\SQLAGENT.OUT
در اینجا خطاهای زیر ثبت شده بودند:
 2013-01-28 20:02:34 - ! [298] SQLServer Error: 780, SQL Server Network Interfaces: The logon attempt failed [SQLSTATE HY000]
2013-01-28 20:02:34 - ! [298] SQLServer Error: 780, Cannot generate SSPI context [SQLSTATE HY000]
2013-01-28 20:02:34 - ! [000] Unable to connect to server ; SQLServerAgent cannot start
2013-01-28 20:02:34 - ! [298] SQLServer Error: 780, SQL Server Network Interfaces: The logon attempt failed [SQLSTATE HY000]
2013-01-28 20:02:34 - ! [298] SQLServer Error: 780, Cannot generate SSPI context [SQLSTATE HY000]
2013-01-28 20:02:34 - ! [382] Logon to server failed (DisableAgentXPs)
2013-01-28 20:02:34 - ? [098] SQLServerAgent terminated (normally)
همانطور که مشخص است مشکل اصلی در عدم توانایی لاگین اکانت SQL Server Agent ذکر شده است.
برای تغییر آن مسیر زیر را طی کنید:
 SQL Configuration manager -> SQL Server Agent -> Logon User -> NT/Local Service
به عبارتی در قسمت SQL Configuration manager، تنظیمات SQL Server Agent را یافته و نوع اکانت آن‌را به Local Service تغییر دهید.
پس از آن سرویس بدون مشکل استارت شد.
مطالب
اتصال و کار با SQL Server توسط VSCode
نگارش‌های بعدی SQL Server چندسکویی بوده و هم اکنون نگارش‌های آزمایشی آن برای لینوکس در دسترس هستند. به همین جهت مایکروسافت افزونه‌ی چندسکویی را برای VSCode به منظور اتصال و کار با SQL Server تدارک دیده‌است که آن‌را می‌توان یک نمونه‌ی سبک وزن Management Studio آن دانست.




دریافت و نصب افزونه‌ی SQL Server مخصوص VSCode

برای افزودن این افزونه، ابتدا در برگه‌ی Extensions، عبارت mssql را جستجو کرده و سپس آن‌را نصب کنید:


پس از نصب آن، مرحله‌ی بعد، ایجاد یک فایل خالی با پسوند sql است.


انجام اینکار ضروری است و شبیه به حالت نصب افزونه‌ی #C می‌باشد. به این ترتیب وابستگی‌های اصلی آن دریافت، نصب و فعال خواهند شد. این ابزارها نیز سورس باز بوده و موتور SQL Formatter، اجرای SQL و Intellisense آن‌را فراهم می‌کند و چون مبتنی بر NET Core. تهیه شده‌است، چندسکویی است.

تا اینجا مزیتی را که به دست خواهیم آورد Syntax highlighting و Intellisense جهت درج واژه‌های کلیدی عبارات SQL است:

و یا اگر بر روی فایل sql جاری کلیک راست کنیم، گزینه‌ی Format Document آن سبب می‌شود تا کدهای SQL نوشته شده، با فرمتی استاندارد، مرتب و یک‌دست شوند:


بنابراین اگر علاقمندید تا فایل‌ها و عبارات SQL خود را فرمت کنید، این افزونه‌ی سبک وزن چندسکویی، یک چنین قابلیت توکاری را به همراه دارد.
همچنین اگر علاقمندید به یک کتابخانه‌ی سورس باز چندسکویی SQL Formatter و SQL Parser دات نتی دسترسی داشته باشید، کدهای Microsoft/sqltoolsservice در دسترس هستند.


اتصال به SQL Server و کار با آن

پس از نصب مقدماتی افزونه‌ی mssql، دکمه‌های ctrl+shift+p (و یا F1) را فشرده و عبارت sql را جستجو کنید:


در اینجا سایر قابلیت‌های این افزونه‌ی نصب شده را می‌توان مشاهده کرد. در لیست ظاهر شده، گزینه‌ی Connect را انتخاب کنید. بلافاصله گزینه‌ی انتخاب پروفایل ظاهر می‌شود. چون هنوز پروفایلی را تعریف نکرده‌ایم، گزینه‌ی Create connection profile را انتخاب خواهیم کرد:


در ادامه باید نام سرور را وارد کرد. یا می‌توانید نام سرور کامل SQL خود را وارد کنید و یا اگر با LocalDB کار می‌کنید نیز امکان اتصال به آن با تایپlocaldb\MSSQLLocalDB  وجود دارد:


سپس نام بانک اطلاعاتی را که می‌خواهیم به آن متصل شویم ذکر می‌کنیم:


در مرحله‌ی بعد، باید نوع اعتبارسنجی اتصال مشخص شود:


چون در ویندوز هستیم، می‌توان گزینه‌ی Integrated را نیز انتخاب کرد (یا همان Windows Authentication).

در آخر، جهت تکمیل کار و دخیره‌ی این اطلاعات وارد شده، می‌توان نام پروفایل دلخواهی را وارد کرد:


اکنون کار اتصال به این بانک اطلاعاتی انجام شده و اگر به status bar دقت کنید، نمایش می‌دهد که در حال به روز رسانی اطلاعات intellisense است.


برای نمونه اینبار دیگر intellisense ظاهر شده منحصر به درج واژه‌های کلیدی SQL نیست. بلکه شامل تمام اشیاء بانک اطلاعاتی که به آن متصل شده‌ایم نیز می‌باشد:


در ادامه برای اجرا این کوئری می‌توان دکمه‌های Ctrl+Shift+E را فشرد و یا ctrl+shift+p (و یا F1) را فشرده و در منوی ظاهر شده، گزینه‌ی execute query را انتخاب کنید (این گزینه بر روی منوی کلیک راست ظاهر شده‌ی بر روی فایل sql جاری نیز قرار دارد):





نگاهی به محل ذخیره سازی اطلاعات اتصال به بانک اطلاعاتی

پروفایلی را که در قسمت قبل ایجاد کردیم، در منوی File->Preferences->Settings قابل مشاهده است:
// Place your settings in this file to overwrite the default settings
{
    "workbench.colorTheme": "Default Light+",
    "files.autoSave": "afterDelay",
    "typescript.check.tscVersion": false,
    "terminal.integrated.shell.windows": "cmd.exe",
    "workbench.iconTheme": "material-icon-theme",
    "vsicons.dontShowNewVersionMessage": true,
    "mssql.connections": [
        {
            "server": "(localdb)\\MSSQLLocalDB",
            "database": "TestASPNETCoreIdentityDb",
            "authenticationType": "Integrated",
            "profileName": "testLocalDB",
            "password": ""
        }
    ]
}
همانطور که مشخص است، کلید mssql.connections یک آرایه است و در اینجا می‌توان چندین پروفایل مختلف را تعریف و استفاده کرد.
برای مثال پروفایلی را که تعریف کردیم، در دفعات بعدی انتخاب گزینه‌ی Connect، به صورت ذیل ظاهر می‌شود:



تهیه‌ی خروجی از کوئری اجرا شده

اگر به نوار ابزار سمت راست نتیجه‌ی کوئری اجرا شده دقت کنید، سه دکمه‌ی تهیه‌ی خروجی با فرمت‌های csv، json و اکسل نیز در اینجا قرار داده شده‌است:


برای مثال اگر گزینه‌ی json آن‌را انتخاب کنید، بلافاصله نام فایلی را پرسیده و سپس این نتیجه را با فرمت JSON نمایش می‌دهد:


ضمن اینکه حتی می‌توان سطرها و سلول‌های خاصی را نیز از این خروجی انتخاب کرد و سپس با کلیک بر روی آن‌ها، تنها از این انتخاب، یک خروجی ویژه را تهیه نمود:



مشاهده‌ی ساختار اشیاء

اگر بر روی هر کدام از اجزای یک کوئری SQL متصل به بانک اطلاعاتی، کلیک راست کنیم، گزینه‌ی Go to definition نیز ظاهر می‌شود:


با انتخاب آن، بلافاصله عبارت کامل CREATE TABLE [dbo].[AppRoles] ظاهر می‌شود که در اینجا می‌توان ساختار این جدول را به صورت یک عبارت SQL مشاهده کرد.



تغییر تنظیمات افزونه‌ی MSSql

در منوی File->Preferences->Settings با جستجوی mssql می‌توان تنظیمات پیش فرض این افزونه را یافت. برای مثال اگر می‌خواهید تا SQL Formatter آن به صورت خودکار تمام واژه‌های کلیدی را با حروف بزرگ نمایش دهد، گزینه‌ی mssql.format.keywordCasing را انتخاب کنید. در کنار آن آیکن قلم ویرایش ظاهر می‌شود. با کلیک بر روی آن، منوی انتخاب uppercase را خواهیم داشت:


پس از این تغییر، اکنون بر روی صفحه کلیک راست کرده و گزینه‌ی Format Document را انتخاب کنید. در این حالت علاوه بر تغییر فرمت سند SQL جاری، تمام واژه‌های کلیدی آن نیز uppercase خواهند شد.