Hi, all.

I'm working with Sybase ASA ISQL 7.0.4.3423.

Sometimes I launch time consuming process from ISQL. While it works, I
want to check the table, which this process is filling, to see the
progress. So, I launch another ISQL session, run count(*) against this
table and get a result. But, if I try to run count(*) again, I always
get the same result! Only thing that helps to get refreshed number is
to disconnect and connect again.

It's a small thing, but it is annoying. Why ISQL acts like this? How to
get current amount of rows from table without disconnecting/connecting?

Thanks!

Cal wrote:
> Hi, all.
>
> I'm working with Sybase ASA ISQL 7.0.4.3423.
>
> Sometimes I launch time consuming process from ISQL. While it works, I
> want to check the table, which this process is filling, to see the
> progress. So, I launch another ISQL session, run count(*) against this
> table and get a result. But, if I try to run count(*) again, I always
> get the same result! Only thing that helps to get refreshed number is
> to disconnect and connect again.
>
> It's a small thing, but it is annoying. Why ISQL acts like this? How to
> get current amount of rows from table without disconnecting/connecting?
>
> Thanks!

Sorry, I did not see any answer...


krithika wrote:
> Cal wrote:
> > Hi, all.
> >
> > I'm working with Sybase ASA ISQL 7.0.4.3423.
> >
> > Sometimes I launch time consuming process from ISQL. While it works, I
> > want to check the table, which this process is filling, to see the
> > progress. So, I launch another ISQL session, run count(*) against this
> > table and get a result. But, if I try to run count(*) again, I always
> > get the same result! Only thing that helps to get refreshed number is
> > to disconnect and connect again.
> >
> > It's a small thing, but it is annoying. Why ISQL acts like this? How to
> > get current amount of rows from table without disconnecting/connecting?
> >
> > Thanks!

On 25 Jan 2006, kasis_100@yahoo.com wrote:
> Hi, all.
>
> I'm working with Sybase ASA ISQL 7.0.4.3423.
>
> Sometimes I launch time consuming process from ISQL. While it works, I
> want to check the table, which this process is filling, to see the
> progress. So, I launch another ISQL session, run count(*) against this
> table and get a result. But, if I try to run count(*) again, I always
> get the same result! Only thing that helps to get refreshed number is
> to disconnect and connect again.
>
> It's a small thing, but it is annoying. Why ISQL acts like this?

It isn't ISQL, its the way databases work. Until a commit is issued,
others shouldn't see the uncommitted work. Your second ISQL session is
just another client that isn't allowed to see the uncommitted work of
some other session, ie the isql session doing the work.

> How to get current amount of rows from table without
> disconnecting/connecting?

Well, you could use the "isolation level read uncommitted" but that
takes understanding transactional handling before you can understand
what you are using it for.

You could instrument the code to select what you are looking for at
particular points in time.

You could commit at particular points in time of the executing process.

--
Galen Boyer

Just wondering if you had disconnected & then connected the first
(where INSERT is being executed) or second (where you are monitoring
the count) ISQL session. If it is first, I think the suggestion on
uncommitted transactions would be the perfect answer. Kindly clarify as
to which session you had reconnected.

Hello.

I am reconnecting second session you mentioned. One, which executes
INSERT, stays connected.

Also, I am not sure, if idea about commits is entirely right. Fact is,
that from first session I launch stored procedure, which, in turn calls
for other stored procedure, it performs designed actions, executes
commit and returns to "main" procedure, which I called from ISQL.

Idea is, that process performs many commits, while I do not see any
changes from second session as long as I do not reconnect it.


Cal

Dhannya wrote:
> Just wondering if you had disconnected & then connected the first
> (where INSERT is being executed) or second (where you are monitoring
> the count) ISQL session. If it is first, I think the suggestion on
> uncommitted transactions would be the perfect answer. Kindly clarify as
> to which session you had reconnected.

As you said, if it is the second session, we do not expect it to behave
the way it does, esp since there are so many commits in between. I am a
rather junior user and hence let us wait for the experts for an
answer...

Cal wrote:

> How to
> get current amount of rows from table without disconnecting/connecting?

To supplement Galen's explanation, you're asking the wrong
question here. A transation is considered an atomic unit
of work, so "current" has no meaning to other users. To
others, the table is either in the "before" state or the
"after" state, and nothing in between.


Larry Coon
University of California

But if there are intermediate commits in Cal's nested stored procedures
(as I understand), isn't it logical that the change in count should
reflect on re-execution of count(*) even when the stored procedure is
being executed?

Also, how would the changes reflect once he disconnects and re-connects
the second session even though the stored procedure has not finished
execution in the first isql session?

On 30 Jan 2006, kasis_100@yahoo.com wrote:
> Hello.
>
> I am reconnecting second session you mentioned. One, which executes
> INSERT, stays connected.
>
> Also, I am not sure, if idea about commits is entirely right.

What is incorrect?

> Fact is, that from first session I launch stored procedure, which, in
> turn calls for other stored procedure, it performs designed actions,
> executes commit and returns to "main" procedure, which I called from
> ISQL.
>
> Idea is, that process performs many commits, while I do not see any
> changes from second session as long as I do not reconnect it.

Okay,

In your original post, you didn't clearly state what was going on. And,
at this point, it still isn't clear, but at least I know commits are
going somewhere in the executing process, which was my third suggestion.

Any chance you could post the executing code and the testing "select
count(*)" you are executing? Without it, I and others will be grasping
at all sorts of straws.

--
Galen Boyer