تفاوت dynaset با snapshot

[seeker]

با سلام
میخواستم از دوستان بپرسم تفاوت dynaset با snapshot در خصیت recrdset type فرم چیه که وقتی روی دایناست قرار میگیره یک فرم که از جدول استفاده میکنه هیچ فرم دیگه ای نمیتونه از اون جدول استفاده کنه ولی در حالت اسنپ شات چندین فرم میتونن در یک زمان از یک جدول استفاده کنن؟

[smderfan]

مقدار پیش فرض Dynaset تعیین می کند که همه شی ء های کنترلی متصل به فیلدهای منبع رکورد مادامی که فیلد زمینه قابل بروز رسانی باشد قابل بروز رسانی هستند در صورتی که فرم شما به یک کوئری مرتبط است. تنظیم Dynaset (بروزرسانی ناسازگار) بیان می کند که همه فیلدها (به غیر از فیلدهایی که از یک عبارت حاصل می شوند و فیلدهای Autonumber) می توانند بروز شوند حتی اگر این بروز رسانی موجب شکستن پیوند بین جداول مرتبط شود (این گزینه معمولاً پیشنهاد نمی شود زیر به کاربر امکان ایجاد تغییری را که منجر به نقض قواعد جامعیت خواهد شد می دهد). تنظیم Snapshot تعیین می کند که داده ها فقط خواندنی هستند و نمی توانند تغییر داده شوند.

منیع : راهنمای جامع اکسس 2003 - جان ویسکاس

[seeker]

ببینم یعنی اگر فرم اسنپ شات تعریف شود دیگر نمیتوان ادیت یا حذف یا اضافه نمود؟

[moustafa]

بله بنوعی رکوردها قفل میشند

[stabesh]

با سلام
مزيتها و معايب اين دو در چيست ؟

Dynasets Vs. Snapshots


When Jet executes a query, the result set returned is either a dynaset or a snapshot. A dynaset is a live, updatable view of the data in the underlying tables. Changes to the data in the underlying tables are reflected in the dynaset, and changes to the dynaset data are immediately reflected in the underlying tables. A snapshot is a non-updatable, unchanging view of the data in the underlying tables. The result sets for dynasets and snapshots are populated in different manners.


Result Set Population

A snapshot is populated by executing a query that pulls back all the selected columns of the rows meeting the query's criteria. A dynaset, on the other hand, is populated by a query that selects only the bookmark (primary key) columns of each qualifying row. These queries are called population queries. In both cases, these result sets are stored in memory (overflowing to disk if very large), allowing you to scroll around arbitrarily.
Microsoft Access is optimized to return answers to you as quickly as possible; as soon as the first screenful of result data is available, Microsoft Access paints it. The remainder is fetched as follows:
User scrolling: Many user actions (for example, page down, go to last record, and search) require Microsoft Access to partially or completely populate the query's result set. A snapshot fetches all data up to the position scrolled to; a dynaset fetches bookmarks (primary keys) up to that point and then fetches a small amount of data surrounding that position. (See the following text for details.)
Idle time: While you are inactive, Microsoft Access populates the query's result set in the background. This allows faster operations when you become active again. A snapshot fetches and stores all selected columns; a dynaset fetches and stores only bookmarks, and no other data. You can control how quickly this idle-time population occurs, using the MSysConf server-based options table.
When the population query reaches the end of the result set, a snapshot does no further data fetching; a dynaset does no more key fetching but will continue to fetch clusters of rows based on those bookmarks, as you scroll around (see below). In addition, if a connection is needed solely for this key-fetching query, it is closed, unless either:
1. It is parameterized. The connection is maintained to allow fast requery (for subforms and parameterized combo boxes), or
2. This would counteract connection-caching, as described above.


Data Fetching

When rows of data are needed (for example, to paint a datasheet), a snapshot has the data available locally. A dynaset, on the other hand, has only keys and must use a separate query to ask the server for the data corresponding to those bookmarks. Jet asks the server for clusters of rows specified by their bookmarks, rather than one at a time, to reduce the querying traffic.
The dynaset behind an Microsoft Access datasheet/form does in fact cache a small window of data (roughly 100 rows surrounding the current record). This slightly reduces the "liveness" of the data but greatly speeds moving around within a small area. The data can be refreshed quickly with a single keystroke and is periodically refreshed by Microsoft Access during idle time. This contrasts with a snapshot, which caches the entire result data set and cannot be refreshed except by complete re-execution of the query.
In addition to background key fetching, a dynaset also fills its 100-row data window during idle time. This allows you to page up or down "instantly" once or twice, provided you give Microsoft Access at least a little idle time.
Microsoft Access exposes this caching mechanism via the Data Access Objects (DAO) through two Recordset properties (CacheStart and CacheSize), and a Recordset method (FillCache). These apply only to dynasets (not snapshots or pass-through queries), and only when the dynaset contains at least some ODBC data. CacheStart and CacheSize indicate the beginning and length (in rows) of the local cache, while FillCache fills the cache with remote data, fetched in chunks, rather than a single row at a time.


Performance Implications

Snapshots and dynasets differ in several performance characteristics due to their different methods of retrieving and caching data. Several points are worth noting:
Snapshots are faster to open and scroll through than dynasets. If your result set is small and you don't need to update data or see changes made by other users, use a snapshot. Set the form's Allow Updating property to "No Tables" to force the form to run on a snapshot. In Basic, use a Snapshot object.
For larger result sets, a dynaset is faster and more efficient. For example, moving to the end of a snapshot requires the entire result set to be downloaded to the client. But a dynaset downloads only the bookmark columns and then fetches the last screenful of data corresponding to those keys.
Dynaset open time and scrolling speed are affected most negatively by the number of columns you select and the number of the query's tables that are output. Select only the columns you need; outputting all columns using Table.* is more convenient but slower. Sometimes joins are used simply as restrictions and don't need to be output at all.
When a dynaset fetches the data for a given set of keys, Memo columns are not fetched unless they are visible on the screen. If scrolling causes them to become visible, they are then fetched. You can improve performance by designing your form so that, by default, Memo columns are not visible. Either place the Memo off the right/bottom edge of the screen or add a button that renders the Memo visible when pushed. In any case, Memos are cached within the dynaset caching window, once fetched.
OLE objects are never fetched in bunches, nor are they stored in the dynaset caching window, because they tend to be quite large. When a row is displayed, the OLE objects are fetched if they are visible. However, the current row's OLE objects are cached, so simple screen-repainting does not require re-fetching.


Asynchronous Query Execution

Jet executes ODBC queries asynchronously if this is supported by the ODBC driver, the network software, and the server. This allows you to cancel a long-running query in Microsoft Access or to switch to another task in the Windows™ operating system while the query runs on the server. Jet asks the server if the query is finished every M milliseconds, where M is configurable, and defaults to 500 milliseconds.
When you cancel a query (or simply close a query before all results have been fetched), Jet calls the ODBC function SQLCancel. SQLCancel discards any pending results and returns control to the user. However, some servers (or their network communication software) do not implement an efficient query-canceling mechanism, so you might still have to wait some time before regaining control.
Asynchronous processing might cause unpredictable results with some network libraries and some servers. These network libraries are often more robust when operating synchronously, owing chiefly to the added complexities of handling multiple asynchronous connections. Client applications are often written to operate fully synchronously, even if interactive; this is simpler to implement and test. You can force Jet to operate synchronously by setting an .ini file option (described earlier in this paper). Also notify your network/server vendor; an upgrade or patch might be available for these problems.
Jet will automatically cancel a long-running query after a configurable amount of time (the default is 60 seconds). If this happens, it does not necessarily mean that the server did not respond during that time or that you have become disconnected. It simply means the query did not return results in the time allotted. If you know a certain query will take a very long time to execute, increase the query's "ODBC Timeout" property. Each query can have its own timeout setting.


Optimization of Find

Against server data, the Find command in the Microsoft Access Edit menu and the Find method in Basic are implemented using one of two strategies: an optimized find or an unoptimized find. The optimized version is used only if:
1. The table/query is a dynaset, not a snapshot.
2. The column is indexed.
3. The Find command on the Edit menu: Match Whole Field or Start of Field, not Any Part of Field.
4. The Find command on the Edit menu: Current Field, not All Fields.
5. The Find command on the Edit menu: not Search as Formatted.
6. Basic: the find restriction is column = value or column LIKE value.
7. Basic: the LIKE string is smith or smith*.
8. Basic: the server supports the LIKE operator on text columns.
The optimized algorithm first executes a query of the following form.
SELECT <bookmark-columns>
FROM table
WHERE <find-restriction>
The resulting bookmarks are sought in the dynaset (which stores bookmarks, not data). Currency is positioned on the first matching bookmark, if any. To find (or not find) a matching bookmark, the dynaset might need to fetch more bookmark column values from the server.
The unoptimized algorithm simply iterates through the rows of the snapshot or dynaset, evaluating the find restriction on each row until a match is found or until the end of the records is reached. Again, this may require substantial fetching from the server.

[stabesh]

به نظر من متن بالا با لينكهاي زير مغايرت داره
http://msdn.microsoft.com/en-us/library/dd942824%28office.12%29.aspx#odc_ac2007_ta_Perform anceTipsToSpeedUpYourAccessDB_SQLServerAndODBCPerf ormanceTips
http://www.connx.com/products/connx/Connx%208.5%20UserGuide/dynasets.htm
http://www.utteraccess.com/forum/speed-snapshot-vs-dynas-t1264439.html

[stabesh]

با سلام
اگر که snapshot برای کوئریهای read only مناسبه پس چرا در تمام مثالهای خود مایکروسافت که recordset یا کوئری جنبه انتخاب داشته از dynaset استفاده میشه ؟
:متفکر:
با تشکر