مشکل یه دستور sqlدر محیط دلفی!

[زهرا قاسمی]

با دستور زیرکاربرمیتونه به صورت داینامیک descriptionفیلدای یه جدول رو ببینه.


SELECT *
FROM ::fn_listextendedproperty (NULL, 'user', 'dbo', 'table', 'perinfo', 'column', default)
این دستور تو محیطsqlجواب میده اما وقتی میخام تو دلفی ازش استفاده کنم errorمیگیره!!در صورتی که بقیه دستورات sqlدر محیط دلفی جواب میده!
میشه بگید چه جوری از این دستور تو محیط دلفی استفاده کنم؟
با تشکر!

[Naficy]

بد نیست بگین چه خطایی می ده.

[vcldeveloper]

fn_listextendedproperty مربوط میشه به زبان Transact-SQL که در MS SQL Server استفاده میشه، دلفی از زبان SQL- 92 که زبانی عمومی تر و محدودتر از Transact-SQL پشتیبانی میکنه. شما نمی تونید مستقیما از دستورات و توابع مخصوص Transact-SQL در دلفی استفاده کنید.

[Naficy]

اگر از ADO استفاده کنید قاعدتا نباید مشکلی باشه.

[زهرا قاسمی]

از ADOاستفاده میکنم ولی syntax errorمیده!

[زهرا قاسمی]

[QUOTE=علی کشاورز]fn_listextendedproperty مربوط میشه به زبان Transact-SQL که در MS SQL Server استفاده میشه، دلفی از زبان SQL- 92 که زبانی عمومی تر و محدودتر از Transact-SQL پشتیبانی میکنه. شما نمی تونید مستقیما از دستورات و توابع مخصوص Transact-SQL در دلفی استفاده کنید[/

QUOTE

پس چی کار باید کنم؟؟ :ناراحت:
آخه دقیقا همین تابع رو میخام!
یعنی میخام description فیلدای یه جدولو به صورت داینامیک به کاربر نشون بدم...

[Naficy]

دلفی ربطی به زبان SQL ندارد. آن مساله به BDE بر می گردد که همانطور که گفتم اگر از ADO استفاده کنید نباید مشکلی داشته باشید.
----------------------------
در مورد مساله فعلیتان؛ False کردن خصوصیت ParamCheck را امتحان کنید.

[m-khorsandi]

درود

شما این دستور رو در ADOQuery مینویسید و پیغام خطای زیر رو میگیرید؟ اگر جواب مثبت هست من دو تا پیشنهاد دارم:
1- لطفا" ADOQuery رو تبدیل به یک ADOStoredProc کنید و همین دستور رو در یک StoredProc بنویسید.
2- ADOQuery رو دست نزنید و یک View از همین دستورات بسازید و نهایتا" یک Select از View ساخته شده
در ADOQuery بزنید.

[vcldeveloper]

در تایید صحبت آقای خرسندی، اینگونه دستورات رو که دلفی پشتیبانی نمیکنه، می تونید در قالب یک View یا StoredProcedure استفاده کنید - ربطی به استفاده از ADO یا BDE نداره.

موفق باشید

[زهرا قاسمی]

باviewمیتونیم اسم جدولی رو که میخایم داینامیک بدیم؟
فکر میکنم view استاتیک عمل میکنه...

[m-khorsandi]

پیشنهاد میکنم خودتون رو بیشتر از این اذیت نکنید، یه StoredProc بنویسید :


CREATE PROCEDURE StP_ShowFieldDescription @Prm_TableName VarChar(100), @Prm_FieldName VarChar(100)
AS
SELECT *
FROM ::fn_listextendedproperty (NULL, 'user', 'dbo', 'table', @Prm_TableName, @Prm_FieldName, default)

[Naficy]

در تایید صحبت خودم باید بگم که دستورات SQL توسط ADO مستقیما به درایور بانک اطلاعاتی ارسال می شن و دلفی هیچکاره س. (مطمئن باشید که این خود بانک اطلاعاتی است که دستورات را دریافت، بهینه و اجرا می کند هر اشکالی هست باید توی خود َِADO باشه)

به نظر من استفاده از stored proc به عنوان آخرین راه، روش خوبیه؛ هرچند پاک کردن صورت مسالس...ضمنا view هم دینامیک عمل می کنه...

[m-khorsandi]

در تایید صحبت خودم باید بگم که دستورات SQL توسط ADO مستقیما به درایور بانک اطلاعاتی ارسال می شن و دلفی هیچکاره س

پس به خاطر همینه که اون Error ای که عکسش رو هم گذاشتم رو در IDE دلفی میبینیم، آره؟؟؟

[vcldeveloper]

در تایید صحبت خودم باید بگم که دستورات SQL توسط ADO مستقیما به درایور بانک اطلاعاتی ارسال می شن و دلفی هیچکاره س
اولا کامپوننت های ADO در دلفی یه Wrapper برای ADO محسوب میشند معمولا قبل از اجرای دستورات روی اونها پردازشهایی انجام میدن، ثانیا اگه یه بار محض رضای خدا روی اون کلمه SQL در IDE دلفی کلیک کنید و F1 رو بزنید، ضرر نمی کنید.

موفق باشید

[m-khorsandi]

ضمنا view هم دینامیک عمل می کنه.

میشه بفرمائید چطوری View داینامیک کار میکنه؟

[Naficy]

میشه بفرمائید چطوری View داینامیک کار میکنه؟
ببخشید چرا من ندیدم که می خوان نام جدولو تغییر بدن؟! تصور کردم منظورشون اینه که هر بار فراخوانیش همون اطلاعات قدیمو می یاره. دوباره معذرت.


اولا کامپوننت های ADO در دلفی یه Wrapper برای ADO محسوب میشند معمولا قبل از اجرای دستورات روی اونها پردازشهایی انجام میدن، ثانیا اگه یه بار محض رضای خدا روی اون کلمه SQL در IDE دلفی کلیک کنید و F1 رو بزنید، ضرر نمی کنید.
بد نیست خودتان هم محض رضای خدا یک سری به Help دلفی بزنید. من به توصیه تون عمل کردم و برای استفاده بقیه مطلبشو اینجا می یارم:

این در ذیل عنوان Using Command objects آمده:


In the ADO environment, commands are textual representations of provider-specific action
requests. Typically, they are Data Definition Language (DDL) and Data Manipulation Language
(DML) SQL statements. The language used in commands is provider-specific, but usually
compliant with the SQL-92 standard for the SQL language.

ضمنا لغت Compliant هم معنی سازگار می ده! (منظور آنکه این استاندارد را پشتیبانی می کند علاوه بر دستورات خاص خودش!)

این هم در عنوان TADOQuery.SQL انتهای مطلبشه


Note : Delphi does not evaluate the SQL sent to the database via a
TADOQuery component. The SQL used must be valid for the particular database type
accessed via ADO. Any error messages passed back to the application will have originated at
the ADO or database level, and so will have error codes and messages specific to those
systems.



خب، من تا قبل از پست قبلیم خودم تست نکرده بودم. و بعد از تست نتونستم راهی پیدا کنم. با توجه به مطالب بالا به نظر می یاد ADO با شیوه ای به SQL Server وصل می شه که باعث چنین خطایی می شه. متاسفانه من هم راهی بجز همون Stored-Procedure به نظرم نمی رسه. واقعا عجیبه!

به امید اندکی حوصله!!!

[vcldeveloper]

بد نیست خودتان هم محض رضای خدا یک سری به Help دلفی بزنید. من به توصیه تون عمل کردم و برای استفاده بقیه مطلبشو اینجا می یارم
حق با شما ست، من اشتباها مطالب مربوط به TQuery.SQL رو به عنوان مرجع ارائه کرده بودم.
امروز خودم هم یک تست انجام دادم و دیدم که غیر از خطای مربوط به syntax پارامترهای یک دستور SQL ،بقیه خطا از سوی Ole Provider for MS SQL Server ارسال میشه، اما باز هم امکان استفاده از تمام قابلیت های Transact-SQL وجود نداره.

به نظر می یاد ADO با شیوه ای به SQL Server وصل می شه که باعث چنین خطایی می شه.
ADO از OLE DB Driver مربوط به SQL Server برای ارسال فرامین به بانک استفاده میکنه و همونطور که در بالا اشاره کردم، خطاها از سوی همین OLE DB Driver دریافت میشند، پس مشکل از ADO نیست. احتمالا یوتیلیتی های MS SQL Server از روش دیگه ایی برای ارسال دستورات استفاده می کنند.

یک نکته خارج از موضوع هم درباره لغت Compliant بگم...Compliant به معنی سازگار، با اون مفهومی که ما از سازگار در ذهنمون داریم، چندان مطابقتی نداره. Compliant به معنی Submissive یا obedient هست، در نتیجه عبارت "compliant with the SQL-92 standard" بمعنی اینه که کاملا مطابق بر دستورات و قوائد استاندارد SQL-92 عمل میکنه، نه اینکه با این استاندارد سازگار هست و در کنار اون با Transact-SQL هم سازگار هست! (چون اصولا Transact-SQL با SQL-92 کاملا سازگار نیست). علت این هم که دلفی ایرادی از دستورات Transact-SQL در کامپوننت های ADO نمیگیره هم فقط به دلیلی هست که خودتون در بالا بهش اشاره کردید (یعنی اصلا پردازشی روی اونها انجام نمیده).
با توجه به مطلب بالا، ترجمه سریع جمله فوق میشه:
...زبان دستورات وابسته به فراهم کننده داده ها ست، اما معمولا برای دستورات SQL از استاندارد SQL-92 پیروی می شود. (اشاره داره به اینکه اکثر RDBMS ها از دستوارت مطابق بر SQL-92 استفاده می کنند)

[Naficy]

ADO از OLE DB Driver مربوط به SQL Server برای ارسال فرامین به بانک استفاده میکنه و همونطور که در بالا اشاره کردم، خطاها از سوی همین OLE DB Driver دریافت میشند، پس مشکل از ADO نیست. احتمالا یوتیلیتی های MS SQL Server از روش دیگه ایی برای ارسال دستورات استفاده می کنند.

موافقم. من هم منظورم این بود که مثلا (بازم مثلا) SQL Server دو شیوه قدیم و جدید برای اتصال داره و ADO از شیوه قدیمی استفاده می کنه در نتیجه SQL Server هم به بعضی دستورات گیر می ده. (این یه مثال بودها!!) احتمال اینکه مثلا دلفی هم باید یه متغیری رو ست بکنه تا ADO از شیوه جدید (فرضی) استفاده کنه هست. اما اینایی که ما می گیم همش حدس و گمانه (البته ممکنه کارگشاهم باشه...)
ضمنا اگه اشتباه نکنم، تابعی که مورد بحثه جزو What's New ی راهنمای SQL Server 2000 بود؛ (درست یادم نیست!) که اگه درست باشه احتمال درستی حدسمونو بالا می بره.


در مورد بحث خارج از موضوعمان در مورد Compliant، باید بگم من برداشتم از سازگار بودن دقیقا همینه که شما می گین، با کمی تفاوت. (چه دقیقنی!) من فکر می کنم سازگاری دو جای متفاوت دو معنا بده. زمانی که در مورد یک مفسر (مثل مفسر دستورات SQL) صحبت می شه که با فلان استاندارد سازگاره، یعنی هرچی مطابق اون استاندارد بش بدی رو می شناسه. (و در این صورت می تونه بازهم دستوراتی برای خودش اضافه کنه) اما وقتی در مورد یک دستور این صحبت می شه، یعنی این دستور جوریه که توی اون استاندارد حتما قابل تشخیصه (و این یعنی هیچ چیز اضافه ای که اون استاندارد نفهمه رو نداره). همونطور که واضحه این دو معنا که می گم از یک جهت هم کاملا هم معنین!!!
به هرحال چه SQL-92 و Transact-SQL قابل تجمیع باشن و چه نباشن (که نیستن) نتیجه برداشت هردوی ما یکیه، چون توی جمله صراحتا ذکر شده "معمولا سازگارند" و نگفته "لزوما سازگارند" و در واقع اصلا بحث روی "سازگار" کار بیهوده ایه، فرقی نمی کنه چه معنیی بده! (اما من به شخصه واقعا مشتاقم که بحث کنم)