چك كردن ديتابيس SQL در هنگام اجراي برنامه

[pandco]

با سلام

ميخوام وقتي برنامه رو اجرا مي كنم چك كنم ببينم SQL 2000 نصب هستش يا STOP نشده يا اينكه ديتابيس مورد نظر در داخل SQL هستش يا نه؟

با AdoConnection با SQL ارتباط برقرار كردم وقتي STOP مي كنم 3 تا پيغام ميده و داخل برنامه ميره اما كار نميكنه و اول چك كنم اگر ديتابيس ايراد داشت پيغام بده و بره بيرون

با تشكر از دوستان

[سعید صابری]

راحت ترین و بی دردسرترین راهش دستوراتت در try...except بنویس.

[pandco]

با سلام
ميشه كد رو بصورت كامل بنويسين من تازه كارم نمي دونم چطوري بنويسم

با تشكر

[pandco]

با سلام
خواهشن يكي از دوستان كمك كنه !!!!!

با تشكر

[سعید صابری]

TRY
دستورات اتصال
except
on E : Exception do
ShowMessage(E.ClassName+' خطا در اتصال: : '+E.Message)
END;

حالا بر هر دلیل دستورات اتصال با خطا روبرو بشه هر کدی در قسمت except اجرا میشه.

[M_Maskout]

با سلام
خواهشن يكي از دوستان كمك كنه !!!!!

با تشكر

شیئ Application، ویژگی‌ها، متدها و وقفه‌های جالبی داره که به کمک اونا می‌شه خیلی از مدیریت‌ها رو روی کل برنامه انجام داد.
پیشنهاد می‌دم یه روتین برای وقفه‌ی OnException اون بنویسین و توی اون وقفه، خطاهای پیش اومده در کل برنامه رو مدیریت کنین، هم برنامه خیلی حرفه‌تر می‌شه، هم دست شما برای انواع کنترل روی کل برنامه در زمان بروز خطا باز می‌شه.
مثلاً در وقفه FormCreate از فرم اصلی برنامه دستور
Application.OnException := OnException;
رو قرار بدین بعد هم روتین OnException رو در ادامه به عنوان یکی از متدهای همین فرم تعریف کنین. یه چیزی مثل این:


uses ComObj;
TfrmMainForm = class(TForm)
procedure FormCreate(Sender: TObject);
procedure OnException(Sender: TObject; E: Exception);
end;

procedure TfrmMainForm.FormCreate(Sender: TObject);
begin
Application.OnException := OnException;
end;

procedure TfrmMainForm.OnException(Sender: TObject; E: Exception);
begin
ShowMessage(E.Message + ' (Error Code: ' + IntToStr(EOleException(E).ErrorCode) + ')');
end;


از پارامتر E برای تشخیص نوع خطا می‌تونید استفاده کنین. وقتی خطایی در برنامه رخ می‌ده، دلفی یه نمونه از کلاس TObject می‌سازه و خطای بوجود اومده رو با اون نمایش می‌ده.
با استفاده از پارامتر E و تبدیل اون به کلاس ساخته شده، می‌شه خطای بوجود اومده رو مدیریت کرد.
در اینجا اگر بجای دستور

ShowMessage(E.Message + ' (Error Code: ' + IntToStr(EOleException(E).ErrorCode) + ')');

از دستور

ShowMessage(E.Message+' ('+E.ClassName+')');
استفاده بشه، در زمان بروز خطا، عبارت داخل پرانتز در پنجره نمایش داده شده، نام کلاسی که خطا رو کنترل کرده (ایجاد کرده) نمایش داده می‌شه.
در خطاهایی که در اثر استفاده از AdoConnection ایجاد می‌شه، نام کلاس، EDatabaseError هست و البته با استفاده از این کلاس نمی‌شه مدیریت چندانی روی خطا انجام داد. اما چون AdoConnection یه شیء OLE هست، می‌شه با استفاده از تبدیل کلاس خطای ایجاد شده به EOleException و استفاده از ویژگی ErrorCode اون کل خطای بوجود اومده رو مدیریت کرد. فقط لازمه کد خطا رو بدونید که برای این منظور می‌تونید از ساختار case ... of و شاخه else اون استفاده کنین یه چیزی مثل این:


case EOleException(E).ErrorCode of
.
.
.
else
ShowMessage(E.Message + ' (Error Code: ' + IntToStr(EOleException(E).ErrorCode) + ')');
end;



با استفاده از ساختار کد بالا شماره خطاهای پیش بینی نشده (فقط خطاهای اشیاء OLE) مشخص می‌شه و می‌شه بعداً این شماره خطاها رو هم در برنامه مدیریت کرد.
توجه: به استفاده از یونیت ComObj در قسمت uses توجه کنید، در غیر اینصورت نمی‌تونین از کلاس EOleException استفاده کنین.

[pandco]

با سلام
تو برنامه چند تا فرم دارم و تو Data Module اتصالات دیتابیس رو انجام دادم و این کد رو تو فرم اصلی برنامه میذارم بازم پیغام میده یعنی قبل از فرم اصلی اتصال دیتابیس انجام میده کجا این برنامه رو قرار بدم ؟ امکان داره یه نمونه برنامه بذارین!!!!

با تشکر از دوستان

[a_mosavian]

شیئ Application، ویژگی‌ها، متدها و وقفه‌های جالبی داره که به کمک اونا می‌شه خیلی از مدیریت‌ها رو روی کل برنامه انجام داد.
پیشنهاد می‌دم یه روتین برای وقفه‌ی OnException اون بنویسین و توی اون وقفه، خطاهای پیش اومده در کل برنامه رو مدیریت کنین، هم برنامه خیلی حرفه‌تر می‌شه، هم دست شما برای انواع کنترل روی کل برنامه در زمان بروز خطا باز می‌شه.
مثلاً در وقفه FormCreate از فرم اصلی برنامه دستور
Application.OnException := OnException;
رو قرار بدین بعد هم روتین OnException رو در ادامه به عنوان یکی از متدهای همین فرم تعریف کنین. یه چیزی مثل این:


uses ComObj;
TfrmMainForm = class(TForm)
procedure FormCreate(Sender: TObject);
procedure OnException(Sender: TObject; E: Exception);
end;

procedure TfrmMainForm.FormCreate(Sender: TObject);
begin
Application.OnException := OnException;
end;

procedure TfrmMainForm.OnException(Sender: TObject; E: Exception);
begin
ShowMessage(E.Message + ' (Error Code: ' + IntToStr(EOleException(E).ErrorCode) + ')');
end;


از پارامتر E برای تشخیص نوع خطا می‌تونید استفاده کنین. وقتی خطایی در برنامه رخ می‌ده، دلفی یه نمونه از کلاس TObject می‌سازه و خطای بوجود اومده رو با اون نمایش می‌ده.
با استفاده از پارامتر E و تبدیل اون به کلاس ساخته شده، می‌شه خطای بوجود اومده رو مدیریت کرد.
در اینجا اگر بجای دستور

ShowMessage(E.Message + ' (Error Code: ' + IntToStr(EOleException(E).ErrorCode) + ')');

از دستور

ShowMessage(E.Message+' ('+E.ClassName+')');
استفاده بشه، در زمان بروز خطا، عبارت داخل پرانتز در پنجره نمایش داده شده، نام کلاسی که خطا رو کنترل کرده (ایجاد کرده) نمایش داده می‌شه.
در خطاهایی که در اثر استفاده از AdoConnection ایجاد می‌شه، نام کلاس، EDatabaseError هست و البته با استفاده از این کلاس نمی‌شه مدیریت چندانی روی خطا انجام داد. اما چون AdoConnection یه شیء OLE هست، می‌شه با استفاده از تبدیل کلاس خطای ایجاد شده به EOleException و استفاده از ویژگی ErrorCode اون کل خطای بوجود اومده رو مدیریت کرد. فقط لازمه کد خطا رو بدونید که برای این منظور می‌تونید از ساختار case ... of و شاخه else اون استفاده کنین یه چیزی مثل این:


case EOleException(E).ErrorCode of
.
.
.
else
ShowMessage(E.Message + ' (Error Code: ' + IntToStr(EOleException(E).ErrorCode) + ')');
end;



با استفاده از ساختار کد بالا شماره خطاهای پیش بینی نشده (فقط خطاهای اشیاء OLE) مشخص می‌شه و می‌شه بعداً این شماره خطاها رو هم در برنامه مدیریت کرد.
توجه: به استفاده از یونیت ComObj در قسمت uses توجه کنید، در غیر اینصورت نمی‌تونین از کلاس EOleException استفاده کنین.

دوست عزیز بارها بحث شده که رویداد OnException برای این هست که نحوه نمایش پیغام رو پیشرفته تر یا بخواهیم لوگ کنیم. این استفاده از این رویداد چندان جالب نیست. تا اونجایی که من می دونم پیغام خطای مناسب در ADO داده میشه و نیازی به کشف کد خطا نیست. اینجوری تنها حجم کد بالا میره بدون اینکه کار مثبتی انجام شه. شیوه minair2004 جذاب تر هست. منتها خوشحال می شم تجربه های شخصی تون رو در اینباره بیشتر بدونم.

[M_Maskout]

دوست عزیز بارها بحث شده که رویداد OnException برای این هست که نحوه نمایش پیغام رو پیشرفته تر یا بخواهیم لوگ کنیم. این استفاده از این رویداد چندان جالب نیست. تا اونجایی که من می دونم پیغام خطای مناسب در ADO داده میشه و نیازی به کشف کد خطا نیست. اینجوری تنها حجم کد بالا میره بدون اینکه کار مثبتی انجام شه. شیوه minair2004 جذاب تر هست. منتها خوشحال می شم تجربه های شخصی تون رو در اینباره بیشتر بدونم.

بله حق با شماست، این پست رو قبل از بحث مورد نظر شما زدم. تمام دانشم رو دارم خرج لاگ کزدن Error تو دلفی می‌کنم، ولی ظاهراً اون چیزی که دنبالشم، تو دلفی وجود نداره.
لاگ کردن Errorها تو VB خیلی راحت انجام می‌شه (البته مثل خیلی کارای دیگه) ولی طبعاً کار با زبان حرفه‌ای‌تر، دانش عمیق‌تری نیاز داره.
برنامه‌های VB با هر جور خطایی از کار می‌افته (مگر اینکه اونا رو Log کنیم) ولی دلفی تقریباً اصلاً اینطور نیست. ولی به نظر من این اشکال رو داره که در صورتیکه تو یه پروسه، خطایی وجود داشته باشه، هیچ جور نمی‌شه اون خطا رو در همون لحظه بر طرف کرد (البته بدون استفاده از بلاک try...except). به نظر آقای کانتو (Marco Cantu)، استفاده زیادی از بلاک مذکور، کار درستی نیست. فکر می‌کنم، اگه راهی وجود داشته باشه تا بشه فقط کد خطاها رو در زمان رخداد پیدا کرد، راحتر می‌شه اونا رو مدیریت کرد. (دارم دنبالش می‌گردم)

[BORHAN TEC]

ولی به نظر من این اشکال رو داره که در صورتیکه تو یه پروسه، خطایی وجود داشته باشه، هیچ جور نمی‌شه اون خطا رو در همون لحظه بر طرف کرد (البته بدون استفاده از بلاک try...except).
میشه در مورد این جمله بیشتر توضیح بدین. یعنی چی که نمیشه خطا رو همون لحظه کنترل کرد؟!!!

به نظر آقای کانتو (Marco Cantu)، استفاده زیادی از بلاک مذکور، کار درستی نیست.
بله، طبیعتاً اگر 200 بلاک try/except تو در تو داشته باشیم باید بگویم که این کار مناسب نیست. ولی کدام برنامه نویسی این کار وحشتناک را انجام می دهد؟؟!! :قهقهه:

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

[a_mosavian]

بله حق با شماست، این پست رو قبل از بحث مورد نظر شما زدم. تمام دانشم رو دارم خرج لاگ کزدن Error تو دلفی می‌کنم، ولی ظاهراً اون چیزی که دنبالشم، تو دلفی وجود نداره.
لاگ کردن Errorها تو VB خیلی راحت انجام می‌شه (البته مثل خیلی کارای دیگه) ولی طبعاً کار با زبان حرفه‌ای‌تر، دانش عمیق‌تری نیاز داره.
برنامه‌های VB با هر جور خطایی از کار می‌افته (مگر اینکه اونا رو Log کنیم) ولی دلفی تقریباً اصلاً اینطور نیست. ولی به نظر من این اشکال رو داره که در صورتیکه تو یه پروسه، خطایی وجود داشته باشه، هیچ جور نمی‌شه اون خطا رو در همون لحظه بر طرف کرد (البته بدون استفاده از بلاک try...except). به نظر آقای کانتو (Marco Cantu)، استفاده زیادی از بلاک مذکور، کار درستی نیست. فکر می‌کنم، اگه راهی وجود داشته باشه تا بشه فقط کد خطاها رو در زمان رخداد پیدا کرد، راحتر می‌شه اونا رو مدیریت کرد. (دارم دنبالش می‌گردم)
دلفی جدا از شباهت های ظاهریش با VB بگونه ای بنیادین با اون فرق داره. شما باید یاد بگیرید مانند دلفی بیاندیشید تا بتونید از تمام امکاناتش بهره بگیرید. سیستم استثنا کارش اینه که مدیریت خطا را از حیطه کار برنامه نویس بیرون می آورد و به VCL و دلفی وا می گذارد. اگر شما استثنای پرتاب شده را نگیرید، دلفی این کار را خواهد کرد.
درباره لوگ، در صورتی که لوگ کردن ساده نظیر ثبت مشخصات استثنا در یک پرونده و فرستاده شدن آن به توسعه گر است، با همان رویداد OnException براحتی قابل پیاده سازی است. برای راحتی کار هم می توانید از سیستم XML استفاده کنید. اگر لوگ های پیشرفته بمانند آنچه که در ویندوز و آفیس می بینیم در نگرش شماست، کمپوننت هایی بمانند EurekaLog می توانند به شما کمک کنند.

[M_Maskout]

بحث داره جالب می‌شه (البته به نظر من)، ولی حیف که جاش توی این تاپیک نباید باشه. حالا...

میشه در مورد این جمله بیشتر توضیح بدین. یعنی چی که نمیشه خطا رو همون لحظه کنترل کرد؟!!!
برای من بارها پیش اومده که در زمان انجام یه کاری تو یه برنامه (یه چیزی شبیه مضمون همین تاپیک)، مثلاً ارتباط دستگاه با دیتا بیس قطع شده. کاربر هم متوجه نشده و یه فرم طولانی رو پر کرده (اسم، فامیل، تلفن، آدرس طولانی و ...) بعد هم دکمه ثبت رو زده. تو برنامه‌های ساخته شده با VB، دقیقاً تو این لحظه یه پیام Run time error روی صفحه میاد و کل برنامه بسته می‌شه. اما تو دلفی حتی پنجره مربوطه هم بسته نمی‌شه (اینکه خوبه!) ولی تو VB می‌شه با یه On Error حساب شده، جلوی بسته شدن برنامه رو گرفت و یه پیغام (در حد فهم همه) به کاربر نشون داد. در اینصورت اگه اشکال مثلاً از قطع موقتی کابل شبکه باشه و کاربر هم فقط یه کم آموزش دیده باشه، مشکل بدون هیچ دردسری برطرف می‌شه. حالا تو دلفی، تا جایی که من باهاش برخورد کردم (البته بدون استفاده از بلاک try...except) پنجره بسته نمی‌شه ولی دیگه عملیات ثبت هم انجام نمی‌شه (می‌دونم این شرایط فقط به خاطر برنامه نویسی افتضاح پیش می‌یاد. ولی پیش می‌یاد!) اینجاست که کاربر خودش با دستان توانای خودش باید پنجره (و یا در بعضی مواقع کل برنامه) رو ببنده و دوباره باز کنه.
پیشنهاد من برای استفاده از یه Error Logger سراسری مثل Application.OnException به همین خاطره. البته به غیر دلفی بودن (=غیر حرفه‌ای بودن) کار تأکید می‌کنم. ولی کار رو پیش می‌بره.


بله، طبیعتاً اگر 200 بلاک try/except تو در تو داشته باشیم باید بگویم که این کار مناسب نیست. ولی کدام برنامه نویسی این کار وحشتناک را انجام می دهد؟؟!! :قهقهه:
‏200 تا رو که اصلاً صحبتش رو نکنید، یه جاهایی شاید 2 یا 3 تا بلاک تو در تو هم یه کار وحشتناک (یا شاید هم خیلی وحشتناک) باشه. منتها تا جایی که من از جمله کتاب آقای کانتو فهمیدم، نظرش اینه که باید برنامه اونقدر دقیق و حساب شده باشه که نیازی به این بلاک نباشه. و تو جاهایی هم که چاره نیست کار رو به خود دلفی بسپاریم.


چنین چیزی در واقعیت برای تمام کلاسهای استثنا امکان ندارد. به عنوان مثال کلاس Exception فاقد فیلدی برای نگهداری کد مربوط به خطا است. به همین دلیل بهتر است که شما با نام کلاس استثنا کار کنید و نه کد مربوط به آن.
بله، درسته. ولی از روی نام کلاس (و البته فکر کنم نوع کلاس بهتره) هم نمی‌شه تمام Exceptionها رو شناسایی کرد. تو VB، امکان نداره دو تا خطای مختلف یه کد رو برگردونه (من که هرگز ندیدم. تو VB هر خطایی یه کد منحصر به فرد برمی‌گردونه البته بعضی از کدها خیلی متفاوتن مثلا 2134478002-، ولی بازم منحصر به فرده). تو دلفی خیلی از خطاها برای اعلان از کلاس‌های مشابه استفاده می‌کنند. (مثلاً تقریباً تمام خطاهای دسترسی به دیتابیس از EDatabaseError استفاده می‌کنن). یه وقتی تو یه سایت (شاید همین سایت) دیدم یکی پیشنهاد داده بود، خطاها رو از روی متن خطا مدیریت کنیم (عملیات مقایسه‌ی رشته‌ای). من به هیچ عنوان فکر نمی‌کنم اینکار، کار درستی باشه. به نظرم باری که در زمان بروز هر خطا روی برنامه می‌یاد خیلی زیاد می‌شه (البته شاید یکی، دوتا رو بشه یه جورایی تحمل کرد)


دلفی جدا از شباهت های ظاهریش با VB بگونه ای بنیادین با اون فرق داره. شما باید یاد بگیرید مانند دلفی بیاندیشید تا بتونید از تمام امکاناتش بهره بگیرید.
کاملاً صحیحه، اما من هیچ کار رو سراغ ندارم که VB (حتی VB.net) بتونه انجام بده و دلفی نتونه. تقریباً مطمئنم که هر کاری با VB (بازم تاکید می‌کنم حتی VB.net) بشه انجام داد، تو دلفی، بهتر، سریعتر و راحتر می‌شه انجامش داد (من بیشتر منظورم دلفی 7 هست وگرنه تو نسخه‌های جدید که این مسأله اینقدر بدیهیه که اصلاً اصل مقایسه اشتباهه).

به هر حال، با همه این تفاسیر از دوستان خواهش می‌کنم، تجربیات و دانش خودشون رو تو این زمینه (مدیریت خطاها تو دلفی) یا تو همون تاپیکی که من درست کردم، و یا (بهتر) تو یه تاپیک دیگه در اختیار بنده و سایرین قرار بدن. فکر می‌کنم می‌تونه خیلی مفید و مؤثر باشه.

[vcldeveloper]

منتها تا جایی که من از جمله کتاب آقای کانتو فهمیدم، نظرش اینه که باید برنامه اونقدر دقیق و حساب شده باشه که نیازی به این بلاک نباشه. و تو جاهایی هم که چاره نیست کار رو به خود دلفی بسپاریم.
همچین برداشتی کلا اشتباه هست!
بلوک های try-except و try-finally در همه زبان هایی که Structural Exception Handling رو پشتیبانی می کنند، به نوعی وجود دارند، و وظیفه برنامه نویس هست که از اونها به درستی استفاده کنه. در برخی از زبان ها مثل جاوا، حتی لازم هست که برنامه نویس قید کنه هر متد ممکنه چه Exception هایی تولید کنه. برنامه نویس باید در طرح خودش مشخص کنه که در هر بخش از برنامه چه Exception هایی ممکنه رخ بدند، و این Exception ها کجا باید مدیریت بشند. برنامه نویسی که بی هدف، برای خودش try-except و try-finally بسازه، موجب کاهش کارایی برنامه و افزایش حجم کد ماشین تولید شده میشه، بدون اینکه چیز خاصی به دست بیاره؛ مثل این برنامه نویس هایی که من می بینم مرتبا بلوک های try-except می نویسند، و بخش except رو خالی میزارند، فکر می کنند این کار یعنی مدیریت خطا !!

اینکه مدیریت خطا رو باید به دلفی بسپاریم هم غلط هست؛ دلفی فقط مکانیزم مربوط به مدیریت خطا رو به ما میده، کار خاصی برای خطای بوجود اومده انجام نمیده. هر کدی که ممکنه Exception تولید کنه، باید جایی مکانیزمی برای مدیریت اون Exception وجود داشته باشه؛ حالا در یک جا ممکنه همون کد خودش Exception رو مدیریت کنه، در جای دیگه ممکنه مجبور باشه اون Exception رو به کد فراخوان خودش منتقل کنه، تا اون کد مدیریت رو انجام بده. البته مدیریت Exception هم Log کرد خطا، یا نمایش پیغام خطا نیست، بلکه مجموعه اقداماتی هست که برنامه برای برطرف کردن اون خطا، یا کاهش اثرات اون خطا یا آگاه سازی کاربر از وجود اون خطا انجام میده. برای بعضی Exception ها، مثل Exception هایی که مستقیما توسط OS به برنامه ارسال میشند، منطقی ترین کاری که برنامه میتونه انجام بده اینه که در کوتاه ترین زمان ممکن، خودش را ببنده، چون اجرای برنامه در اون شرایط میتونه منجر به بروز آسیب های جدی تر به داده های کاربر یا سایر بخش های برنامه بشه. نمونه این رفتار رو در سیستم عامل ویندوز در اون خطاهای معروف صفحه آبی (BSoD) می بینید که در اون حالت، ویندوز به این نتیجه میرسه که ادامه کارش ممکنه موجب بروز مشکلات جدی تر بشه، و بلافاصله بعد از دامپ کردن داده های کرنل، خودش رو از کار میاندازه.

پس باید اول بدونید Exception چی هست، اثراتش چی هست، مکانیزم های کنترل Exception چی هست، اصلا SEH چی هست؛ بعدش مشخص کنید که در برنامه شما باید این مدیریت به چه شکلی انجام بشه؛ و نهایتا اون طرح تون رو با استفاده از ابزارهای موجود پیاده سازی کنید. وقتی این کار رو نکنید، به اینجا می رسید که برنامه نوشته شده با VB بسته نمیشه، برنامه نوشته شده با دلفی بسته میشه!

[pandco]

با تشكر از دوستان
مطالبي كه عنوان كرديد خيلي مفيد بود ولي من همچنان مشكلم رو دارم در صورت امكان كمك كنيد!!!
من در اون جايي كه با برنامه ارتباط برقرار ميكنه از Try استفاده كردم اما قبل از اين برنامه ايراد ميگيره
با تشكر

[pezhvakco]

سلام :

تو برنامه چند تا فرم دارم و تو Data Module اتصالات دیتابیس رو انجام دادم و این کد رو تو فرم اصلی برنامه میذارم بازم پیغام میده یعنی قبل از فرم اصلی اتصال دیتابیس انجام میده کجا این برنامه رو قرار بدم ؟

من در اون جايي كه با برنامه ارتباط برقرار ميكنه از Try استفاده كردم اما قبل از اين برنامه ايراد ميگيره
شما در برنامه و قبل از کامپایل ارتباط را False نمایید .
پیشنهاد میکنم یک رابط اصلی مانند یک ADOConnection برای ارتباط داشته باشید و دیگر ابزار ها رو از راه اون به بانک ارتباط بدین و با این روش در هنگام اجرای برنامه ابتدا وصل شدن (Connect) همین ADOConnection رو بررسی نمایید و اگر شد دیگر ابزار را وصل نمایید .
try
ADOConnection.Connected:=True;
//-- Connect Other =>
except on E: Exception do
//-- Error -
end;

[bootshow]

اگر میخواهید وقتی ارتباط با دیتابیس قطع میشود، کاربر متوجه شود باید از رویدادهایی مثل BeforClose جدول استفاده کرد.
شما اگر بجای اجرای برنامه با F9 از F8 استفاده کنید،میبینید که datamodule قبل از فرم اصلی ایجاد(create) میشود.باید کدهای خود را در DataModuleCreate بنویسید.یونیت Forms را به DataModule اضافه کنید و در صورتیکه ارتباط با بانک برقرار نشد پس از نمایش پیغام خطا از Application.Terminate استفاده کنید.

procedure TDataModule1.DataModuleCreate(Sender: TObject);
begin
try
ADOConnection.Connected:=True;
//-- Connect Other =>
except on E: Exception do
//-- Error -
Application.Terminate;
end;
end;

[pandco]

با سلام
با تشكر از راهنمايي دوستان من از كد بالا استفاده كردم وقتي ديتابيس run هستش كد بخش اولي رو اجرا ميكنه و connection رو true ميكنه و ميشكلي پيش نمياد ولي وقتي ديتابيس stop هستش بازهم هم خطا ميگيره كه ديتابيس رو پيدا نميكنه. امكان داره يه نمونه كد كامل دوستان لطف كنن.

با تشكر