Snapshot or Dynaset?
odecio@ISF.COM
Monday, February 19, 1996
Environment: VC++ 4.0 / NT 3.51 Service Pack 3
Can anyone give me some ideas on choosing Snapshot or Dynaset when
using CRecordset? What are the fundamental differences, and which
concepts are to be analyzed to support the decision?
Thanks for your thoughts,
Otavio
Joe Ficara -- joef@kofax.com
Tuesday, February 20, 1996
A snapshot is typically quick than a Dynaset, however and this is a
BIG however Snapshots are read only! If you need to update the data
use a Dynaset. That's the big difference. There are several
performance related articles on MSDN which I have found very useful,
check it out if you have access to this resource. (Note most of them
are under VB or ACCESS but they apply to C++ in a general sense also.)
Markus Sveinn Markusson -- markus@mmedia.is
Wednesday, February 21, 1996
[Mini-digest: 2 responses]
odecio@ISF.COM wrote:
>
>
> Environment: VC++ 4.0 / NT 3.51 Service Pack 3
>
>
> Can anyone give me some ideas on choosing Snapshot or Dynaset when
> using CRecordset? What are the fundamental differences, and which
> concepts are to be analyzed to support the decision?
>
> Thanks for your thoughts,
>
> Otavio
>
Aside from the type differences one thing comes to mind. Opening snapshots
probably means that you have to load all records from the original table(s)
into your application. This can be quite time consuming. Opening a dynaset
only opens a pointer to it, I believe.
Markus Sveinn Markusson
Reykjavik, Iceland
-----From: Joe Willcoxson
Joe Ficara wrote:
>
> A snapshot is typically quick than a Dynaset, however and this is a
> BIG however Snapshots are read only! If you need to update the data
> use a Dynaset. That's the big difference. There are several
> performance related articles on MSDN which I have found very useful,
> check it out if you have access to this resource. (Note most of them
> are under VB or ACCESS but they apply to C++ in a general sense also.)
That is not true. You can update snapshots! The difference is that if someone
else updates a record and then you scroll to it, a dynaset will reflect those
changes. If you use a snapshot, the data will not reflect the changes unless you
perform a requery. If you update data in a snapshot, the data will be changed in
both the record set and in the database.
If you are using an Access database, then you will have a choice of using a
snapshot or dynaset. My experience with Sybase is that you can only use a
snapshot.
--
Joe Willcoxson
My at home homepage: http://users.aol.com/chinajoe
#include
All opinions are wholly my own.
Anatoly Tuzovsky -- TOMO@cc.tpu.edu.ru
Thursday, February 22, 1996
Good Day!
It seems for you will be interesting articl on MSDN(www.microsoft.
com/msdn/library/library.htm) "ODBC:Architecture,Performance,
and Tuning".
Here is some remarks from it..
Performance implications
------------------------------------
Snapshots and dynasets differ in several performance characte-
ristics due to their different methods of retrieving and caching
data.
Several points are worth noting:
- Snapshots may be faster to open and scroll through than
dynasets. If your result set is small, contains no Memo or
BLOB data, and you don't need to update data or see changes
made by other users, use a snapshot. In Microsoft Access,
set the form's Allow Updating property to "No Tables" to force
the form to run on a snapshot. In Visual 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 key columns and then fetches the
last screen 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/BLOB 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 clicked. 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 refetching.
Hope this helps,
Anatoly Tuzovsky
tomo@cc.tpu.edu.ru
Mike Blaszczak -- mikeblas@msn.com
Saturday, February 24, 1996
If you're using DAO, the same issues are covered in the "Jet Database Engine
Programmer's Guide" from Microsoft Press.
.B ekiM
const TCHAR sz[] = _T("Blaszczak/Esch in '96!");
----------
From: owner-mfc-l@netcom.com on behalf of Anatoly Tuzovsky
Sent: Thursday, February 22, 1996 02:44
Good Day!
It seems for you will be interesting articl on MSDN(www.microsoft.
com/msdn/library/library.htm) "ODBC:Architecture,Performance,
and Tuning".
Here is some remarks from it..
[snipola]
| Вернуться в корень Архива
|