تریگر روی جداول Tmp

[aliasghar]

سلام

آیا میشه روی جداول موقت (Create Table #Test) هم تریگر داشت؟

[AminSobati]

دوست عزیزم متاسفانه این کار امکان پذیر نیست. البته یک دلیل منطقی که من فکر میکنم این هست که Trigger کاربرد اصلیش در هنگام Data Modification توسط کاربرهاست. در این زمان شما اطلاعی از اینکه به فرض چه موقع یک رکورد اضافه شد یا حذف شد ندارین، لذا انجام بعضی کارها رو در Trigger به عهده SQL Server میگذارید. در مورد جداول موقتی، اینها برای Data Entry در اختیار کاربر قرار نمیگیرن و برای کارهای موقتیه خود برنامه نویس کاربرد دارن. لذا زمانیکه شما یک جدول موقتی ایجاد میکنید و در اون رکوردی قرار میدین، دقیقا از کارهایی که روی جدول انجام میدین باخبر هستین و انجام کارهای مرتبط دیگر رو نیازی ندارید تا به Trigger محول کنید.
از طرف دیگه جداول موقتی در tempdb ساخته میشن ولی Triggerها باید در دیتابیس اصلی باشند که این جدایی میتونه مشکل ساز باشه.
موفق باشید،
امین ثباتی MCSD

[aliasghar]

آقای ثباتی
از پاسخ شما ممنون پس اگه میشه نظر خودتون را راجع به مطلب زیر بیان کنید
در بسیاری مواقع لازم میشه ابتدا داده ها را در جداولی بصورت موقت نگهداری کنیم و اگر کاربر موافق با ثبت عملیات باشه داده های ذخیره شده در جداول موقت را پس از یکسری پردازش بصورت دائم ثبت کنیم
نمونه بارز اون فاکتور خرید و فروش است که ابتدا کالاها را در یک جدول بطور موقت ثبت کرده و اگر کاربر موافق به صدور فاکتور بود داده ها را ذخیره کنیم

حالا شما چه راه حلی را برای اینکار (البته با پردازش داده ها در سرور) پیشنهاد میکنید؟
اگه در مورد این مطلب راه وروش خاصی هم در دروس Microsoft هست و شما از اونه اگاهید لطفا به من هم آموزش بدین

ممنون

[AminSobati]

دوست عزیزم،
مثال قشنگی زدین از کاربرد جداول موقتی. این یک سناریوی متداول هست که راه حل های متنوعی هم (بسته به شرایط) براش وجود داره. مثلا اگر از یک Thick Client (مثل VB) استفاده میکنید، آیتمهای خرید در فاکتور رو میتونید در یک Recordset مستقل موقتا ذخیره کنین و بعد از موافقت کاربر اونها رو به سرور بفرستین. اگر از Thin Client (مثل ASP) استفاده میشه شاید بهتر باشه همونطور که اشاره داشتین با جداول موقتی کار کنین.
اما من هنوز دقیقا نمیدونم چرا به Trigger احساس نیاز میکنین. اگر از طریق Stored Procedure کار ذخیره سازی رکوردها در جدول موقتی رو انجام بدین، دستتون برای هر نوع پردازش Server Side بازه.
از طرفی، Trigger فقط در لحظه Insert یا Update یا Delete وارد عمل میشه. اگر بعد از موافقت کاربر با ثبت اطلاعات قصد دارید پردازشی رو جدول موقتی انجام بدین، این کار از عهده Trigger ساقطه.
شاید با توضیح بیشتر شما بشه راه حل بهتری پیدا کرد.
موفق باشین

[aliasghar]

آقای ثباتی عزیز
از اینکه لطف می کنید و در حل این مسائل به من کمک میکنید متشکرم
اصل مساله از این قراره که من در حال طراحی یک Application خرید و فروش هستم که باید بصورت Client , Server نوشته بشه
من برای اینکار از Sql Server به عنوان Engeene استففاده میکم
به مرحله ای رسیدم که طبق گفته های بالا باید اطلاعات فاکتور را در جداول موقت ذخیره کنم و پس از تصدیق کاربر اونها را به جداول اصلی انتقال بدم
البته اصل تریگر و پروسجرهای من بعد از انتقال به جداول اصلی انجام میشه ولی برای نگهداری اطلاعات موقت (جزییات فاکتور) 3 روش به ذهن من خطور کرده
1) بطور کل و برای همیشه یک جدول به عنوان temp برای هدر فاکتور ویکی برای detail خرید درست کنم
مزایا : 1 - در صورت بروز اشکال در حین ورود اطلاعات به این جداول مثلا برق رفتن ، میتوان بعد از راه اندازی دوباره سیستم از اطلاعات این جداول استفاده کرد
2 - چون برای Integrity بهتر تصمیم گرفتم یکسری تریگر بر روی جدول Detail قرار بدهم که پس از رورد یا حذف هر رکورد به فاکتور رکورد مربوطه
را در header بروز رسانی کنه مثال : با اضافه شدن هر رکورد به Detail فیلد جمع مبلغ فاکتور در Headre با استفاده از تریگر تصحیح بشه

اشکال : چون برنامه بصورت چند کاربره تهیه میشه من مجبورم تمهیداتی برای صحت اطلاعات چندین کاربر که بطور همزمان مثلا در حال صدور فکتور هستند انجام بدهم چونکه اطلاعات موقت همه
client ها تنها در همان دو جدول موقت برای header , detail نگهداری میشه

2) برای ذخیره داده ها موقت از جداول موقت بانک اطلاعاتی که در Database Tempdb ذخیره میشه استفاده کنم
مزایا : بطور پیش فرض هر Client دارای جداول داده های موقت برای خودش میشه که اشکال روش اول از بین میره

معایب:بروی این جداول من نمیتونم Trigger تعریف کنم و در ضمن با بروز حادثای مثل رفتن برق تمام داده های این جداول از بین میره پس مزایای روش بالا هم از بین میره

روش سوم هم اینه کهجداول موقت را در جداول فیزیکی که در سطح Local خود Client ها ایجاد میشه نگهداری کنم از قبیل جداولی که میتونم با Paradox ایجاد کنم
ولی اشکال این روش اینه که داده های موقت در Server ذخیره نمیشن پس در هنگام صدور مثلا فکتور سرور و شبکه با حجم قابل توجهی داده روبرو میشن که باید بر روی اونها پردازش
انجام بشه

حالا به نظر شما بهترین روش کدومه
در ضمن من در مورد مفاهیم RecordSet و Thin , Thik که در پیام قبلی به کار برده بودین مشکل دارم اگه میشه در این موارد هم توضیح مختصری بفرمایید

[AminSobati]

علی اصغر جان،
چه نیازی هست که با ورود هر Detail، جمع خرید رو در جدول Master (یا همون Header) به روز کنین؟ هر وقت کاربر تایید کرد، موقع Insert به جدول اصلی، این محاسبه رو انجام بدین.
ولی با فرض به اینکه محاسبه مجموع خرید ضرورت داشته باشه، شما میتونین اطلاعاتی که توسط ده ها کاربر به طور همزمان وارد میشه رو در دو جدول عادی ذخیره کنین (که طبیعتا این حالت اجازه ساخت Trigger رو میده). برای تمایز رکورد کاربرها، میتونین یک عدد Random تولید کنین و اون رو برای رکوردی که در Master و Detail موقتا وارد میشه، در فیلد دیگری در همون دو جدول ثبت کنین. به این صورت جزییات خرید هر کاربر، با داشتن یک کد یونیک از بقیه متمایز میشه. موقعی که باید SUM بگیرین و جمع فاکتور محاسبه بشه، با استفاده از شرط گذاشتن توسط WHERE، فقط جمع خرید از Detail برای یک فاکتور خاص رو بدست میارین، نه جمع همه رکوردهای موجود در Detail رو.
-----------------------
Thick Client: کلاینتی که توانایی لازم برای اجرای برنامه های نسبتا سنگین مثل VB رو داره.

Thin Client: کلاینتی که توانایی محدودی داره و استفاده از یک Browser مثل Internet Explorer براش ایده آل هست تا بشه ازش استفاده کاربردی کرد. طبیعتا اگر مخاطبان ما از این نوع هستند، زبان برنامه نویسی مثل ASP رو انتخاب میکنیم.

نکته: امروزه با پیشرفت و ارزان شدن سخت افزار، تقریبا همه کلاینتها Thick Client در نظر گرفته میشن.

Recordset: یکی از آبجکتهای ADO که در تعریف گفته میشه: یک جدول مجازی مستقر در حافظه کلاینت.
-----------------------
راستی شما از چه زبانی دارین استفاده میکنین؟ چون امکانات دیگه ای هم برای هدف شما وجود داره.

[aliasghar]

آقای ثباتی :
راستش هدف من از این همه پرچونگی (که امیدوارم سر شما را به درد نیاورده باشم) انتخاب بهتریت روش برای انجام این کار هست
روشی که کمترین بار را روش شبکه و سرور ایجاد کنه و بعد از مدتی یا به علت بالا رفتن Client ها باعث کند احتمالی برنامه نشه
( پس حتی اگه این بهتر باشه به سادگی به سادگی میشه اون تریگر را از روی جدول Temp بردارم ==> چون هنوز اصلا" ننوشتمش)
پس خواهش میکنم به من بگید شما کدوم یک از راههای بالا را برای انجام چنین کاری انتخاب میکنید :flower:

در ضمن من از محیط دلفی برای نوشتن Application استفاده میکنم. این نرم افزار چه امکانات ویژه ای برای این امر در اختیار من قرار میده؟

خیلی خیلی خیلی ممنون

[AminSobati]

خواهش میکنم دوست عزیز،
ببینم شما مگه از ADO در دلفی استفاده نمیکنین؟

[aliasghar]

من از SDAC استفاده میکنم که تمام امکانات ADO را در اختیارم قرار میده ولی نمی دونم چه ابزاری در ADO هست که می تونه کمک بارزی به من بکنه؟

[AminSobati]

علی اصغر جان،
در ADO به خوبی از امکانات Recordset میتونین برای حل این مشکل استفاده کنین. نمیدونم در دلفی یا SDAC که گفتین چه چیزی معادل Recordset وجود داره. به هر حال من قابلیت اون رو توضیح میدم، پیدا کردن مشابهش با شما!
همونطور که مختصرا تعریف کردم، Recordset یک Table مجازی هست که در حافظه کلاینت تشکیل میشه. شما میتونین برای نگهداری رکوردهای موقتی فاکتور ازش استفاده کنین. اما برای اینکه از خطراتی مثل قطع برق و غیره که عنوان کردید اطلاعات فاکتور رو حفظ کنین، Recordset یک متد داره به اسم Save که اطلاعاتش رو به صورت Local روی هارد کلاینت ذخیره میکنه (به فرمت باینری یا حتی XML). میشه احتیاطا بعد از ورود هر رکورد به Recordset یکبار Save انجام بدیم که خیلی هم سریع هستش و ضمنا چون روی کلاینت صورت میگیره، ترافیکی در شبکه ایجاد نمیکنه. حالا اگر اتفاقی بیافته یا حتی کاربر PC رو خاموش کنه و فردا کار Data Entry رو بخواد ادامه بده، Recordset میتونه مجددا اطلاعاتش رو از کلاینت بخونه و هر وقت ورود اطلاعات تموم شد و تایید صورت گرفت، ارتباط رو با SQL Server برقرار میکنیم و عمل Insert اصلی انجام میشه. این روش به Disconnected Recordset معروف هست.
این روش چند حسن داره:
- امنیت رکوردها و اطلاعاتی که کاربر وارد کرده از نظر بروز مشکلات احتمالی
- هیچ باری روی شبکه نمیندازه
- پردازش اطلاعات توسط Recordset بسیار راحت هست(به خاطر سهولت استفاده از اون)

امیدوارم به حل مشکل شما نزدیک شده باشیم.
موفق باشید