V60
شنبه 16 دی 1385, 01:12 صبح
سلام
این روشی را که می نویسم ، تازه کشف کردم!!! D:
من چند جدول دارم بر فرض مثال
search
enter
Factor
و غیره
برای تمام جداولم نیاز است که ابتدا فرد مورد نظرم را درون جدول اول یعنی همان search جستجو کنم ، حال اگر بخواهم از کوریها استفاده کنم باید به ازای هر جدول به جز جدول "جستجو" یک کوری بنویسم که مشترک بین جدول "جستجو" و جدول دوم باشد، به نظرم ممکن است مشکلاتی ایجاد کند از جمله اینکه وقتی من این کد را می نویسم
search.id=Factor.id
تمام کسانیکه در جدول جستجو هستند ولی در جدول فاکتور نیستند را نشان نمی دهد . برای حل این مشکل فکر کردم می توان فرمهای ویرایش و ایجاد کردن را از هم جدا کنم و بعد کوریهای جستجویشان را از هم جدا کنم !! ولی دیدم کار خیلی سختی است ، یعنی یک جورایی تنبلیم اومدD:
البته کاربر هم دوست ندارد به فرمهای مختلفی مراجعه کند و دوست دارد تمام کارهایش را از طریق فرمهای کمتری انجام دهد .
مشکل دیگر هم این است که باز هم فکر می کنم که کوریهایی که روی یک جدول نوشته می شوند سرعتی به مراتب بالاتر از کوریهایی هستند که روی دو جدول نوشته می شوند. و هرچقدر فیلدهای جدول " جستجو" کمتر باشد مطمئنن سرعت جستجو بسیار بالا می رود. به همین علت یک فکری به سرم زد که برای شما توضیح میدهم، هدف اولم از گفتن این حرف به اشتراک گذاشتن اطلاعات و هدف دومم این است که اگر کسی روش بهتر یا بهبودی در این روش سراغ دارد به من بگوید، متشکر .
اما روش : ابتدا من در جدول "جستجو" فیلدی به نام ( مثلا F) از نوع عددی تعریف کردم ، که هر موقع قرار شد رکوردی با همین ای دی در جدول Factor ایجاد شود این فیلد را مقدار دهی می کنم برای مثال مقدار یک ، بعد من یک کوری نوشتم که فقط از جدول "جستجو" استفاده می کردم ، در این حالت من بعد از اینکه فرد را در جدول "جستجو "پیدا کردم و دکمه تایید نهایی را تعبیه کردم که با زدن این کلید به فیلد F نگاه می شود اگر مقدار دهی شده بود از دستور locate استفاده می کنم و اگر نشده بود از دستور append استفاده می کنم .
ولی یک موردی تو ذهنم بود و اون اینکه وقتی طرف دکمه تایید نهایی را می زند ممکن است به علت وجود آن رکورد زمان زیادی طول بکشد به خاطر همین بازهم نشتستم فکر کردم ( شاید هم دراز کشیده بودم یادم نیست) و باز به یک راهی رسیدم که می توانست در خیلی از مواقع جواب بدهد و حداقل از دستو locate تا جایی که ممکن بود استفاده نکنم و آن این بود ، که شماره رکوردی را که ای دی فاکتور در زمان ایجاد رکورد داشت را به جدول search منتقل کردم و در فیلد دیگری به نام F_no قرار دادم و با این کار به جای استفاده از دستور locate ابتداز از دستور adotable1.recno=f_no استفاده می کنم و در صورتیکه ای دی مربوط به آن با ای دی جدول "جستجو " تطابق داشت به هدف رسیده ایم و در صورتیکه نبود ، باز هم می توانیم ای دی رکوردهای بالایی و پایینی را چک کنیم تا هر شعاعی که دوست داشتید مثلا من تا 5 رکورد را چک می کنم یعنی 5 رکورد بالایی و 5 رکورد پایین را چک می کنیم و باز هم اگر جواب نداد نهایتا از locate استفاده می کنم ، البته می دانید که چرا ممکن است شمار رکورد جواب ندهد ، به خاطر اینکه ممکن اطلاعات رکورد بالای آن حذف شده باشد .
البته در پایان می توان دکمه ای در برنامه اضافه کرد که به مرتب کردن اطلاعات بپردازد ،متوجه منظورم هستید که ، یعنی مثل برنامه هایی که قبلا توی فاکس پرو نوشته می شد و می نوشتند مرتب کردن اطلاعات ( که من نمی فهمیدم چی کار می کرد ، ولی فکر می کنم روی ایندکس ها کار می کرد ) ، ما هم همین کار را بکنیم.
خب این بود اونچی من فکر کردم ، حالا لطفا نظر بدید. خیلی متشکر می شوم از مدیران اگر آنها هم این روش را تست کنند . با تشکر.
این روشی را که می نویسم ، تازه کشف کردم!!! D:
من چند جدول دارم بر فرض مثال
search
enter
Factor
و غیره
برای تمام جداولم نیاز است که ابتدا فرد مورد نظرم را درون جدول اول یعنی همان search جستجو کنم ، حال اگر بخواهم از کوریها استفاده کنم باید به ازای هر جدول به جز جدول "جستجو" یک کوری بنویسم که مشترک بین جدول "جستجو" و جدول دوم باشد، به نظرم ممکن است مشکلاتی ایجاد کند از جمله اینکه وقتی من این کد را می نویسم
search.id=Factor.id
تمام کسانیکه در جدول جستجو هستند ولی در جدول فاکتور نیستند را نشان نمی دهد . برای حل این مشکل فکر کردم می توان فرمهای ویرایش و ایجاد کردن را از هم جدا کنم و بعد کوریهای جستجویشان را از هم جدا کنم !! ولی دیدم کار خیلی سختی است ، یعنی یک جورایی تنبلیم اومدD:
البته کاربر هم دوست ندارد به فرمهای مختلفی مراجعه کند و دوست دارد تمام کارهایش را از طریق فرمهای کمتری انجام دهد .
مشکل دیگر هم این است که باز هم فکر می کنم که کوریهایی که روی یک جدول نوشته می شوند سرعتی به مراتب بالاتر از کوریهایی هستند که روی دو جدول نوشته می شوند. و هرچقدر فیلدهای جدول " جستجو" کمتر باشد مطمئنن سرعت جستجو بسیار بالا می رود. به همین علت یک فکری به سرم زد که برای شما توضیح میدهم، هدف اولم از گفتن این حرف به اشتراک گذاشتن اطلاعات و هدف دومم این است که اگر کسی روش بهتر یا بهبودی در این روش سراغ دارد به من بگوید، متشکر .
اما روش : ابتدا من در جدول "جستجو" فیلدی به نام ( مثلا F) از نوع عددی تعریف کردم ، که هر موقع قرار شد رکوردی با همین ای دی در جدول Factor ایجاد شود این فیلد را مقدار دهی می کنم برای مثال مقدار یک ، بعد من یک کوری نوشتم که فقط از جدول "جستجو" استفاده می کردم ، در این حالت من بعد از اینکه فرد را در جدول "جستجو "پیدا کردم و دکمه تایید نهایی را تعبیه کردم که با زدن این کلید به فیلد F نگاه می شود اگر مقدار دهی شده بود از دستور locate استفاده می کنم و اگر نشده بود از دستور append استفاده می کنم .
ولی یک موردی تو ذهنم بود و اون اینکه وقتی طرف دکمه تایید نهایی را می زند ممکن است به علت وجود آن رکورد زمان زیادی طول بکشد به خاطر همین بازهم نشتستم فکر کردم ( شاید هم دراز کشیده بودم یادم نیست) و باز به یک راهی رسیدم که می توانست در خیلی از مواقع جواب بدهد و حداقل از دستو locate تا جایی که ممکن بود استفاده نکنم و آن این بود ، که شماره رکوردی را که ای دی فاکتور در زمان ایجاد رکورد داشت را به جدول search منتقل کردم و در فیلد دیگری به نام F_no قرار دادم و با این کار به جای استفاده از دستور locate ابتداز از دستور adotable1.recno=f_no استفاده می کنم و در صورتیکه ای دی مربوط به آن با ای دی جدول "جستجو " تطابق داشت به هدف رسیده ایم و در صورتیکه نبود ، باز هم می توانیم ای دی رکوردهای بالایی و پایینی را چک کنیم تا هر شعاعی که دوست داشتید مثلا من تا 5 رکورد را چک می کنم یعنی 5 رکورد بالایی و 5 رکورد پایین را چک می کنیم و باز هم اگر جواب نداد نهایتا از locate استفاده می کنم ، البته می دانید که چرا ممکن است شمار رکورد جواب ندهد ، به خاطر اینکه ممکن اطلاعات رکورد بالای آن حذف شده باشد .
البته در پایان می توان دکمه ای در برنامه اضافه کرد که به مرتب کردن اطلاعات بپردازد ،متوجه منظورم هستید که ، یعنی مثل برنامه هایی که قبلا توی فاکس پرو نوشته می شد و می نوشتند مرتب کردن اطلاعات ( که من نمی فهمیدم چی کار می کرد ، ولی فکر می کنم روی ایندکس ها کار می کرد ) ، ما هم همین کار را بکنیم.
خب این بود اونچی من فکر کردم ، حالا لطفا نظر بدید. خیلی متشکر می شوم از مدیران اگر آنها هم این روش را تست کنند . با تشکر.