[fdo-internals] Counting rows in managed IFeatureReader

[Orest Halustchak]

If the server supports a serializable isolation level, then you can rely on it, but that implies read locks being applied which can impact the operations of other users. Otherwise, in a multi-user update situation, there is always a possibility that data changes between selects. I think SQL Server supports a snapshot type of isolation that doesn't need read locks, but I'm not sure of the overhead of that option.

A question for Maksim for his application is why he needs the count before getting the data rather than knowing it after all the objects have been selected?

Thanks,
Orest.

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Wednesday, April 23, 2008 12:32 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Counting rows in managed IFeatureReader

So, there is no safe way of getting the count of features that are going
to be returned?

Jason

-----Original Message-----
From: Orest Halustchak
Subject: RE: [fdo-internals] Counting rows in managed IFeatureReader

Even with transactional support, you don't have a guarantee that two
selects will return the same results unless the server supports a
snapshot or serializable type of transaction isolation level, which is
not usually default. Typical isolation levels are read-committed. But,
this would be the same case regardless of whether you did a select
aggregates and then a select versus running a select twice.
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals