Board index » jbuilder » Status Bits

Status Bits


2003-12-03 03:18:43 AM
jbuilder0
JB8- Only one row is changed in a dataset. The row is refetched. The
changesPending method always returns true. The resetPendingStatus does not
change the result of the changesPending method. I use
resetPendingStatus(row, true) on both the dataset and storagedataset. Makes
no difference. Any ideas?
 
 

Re:Status Bits

In < XXXX@XXXXX.COM >Ted Slate wrote:
Quote
JB8- Only one row is changed in a dataset. The row is refetched. The
changesPending method always returns true. The resetPendingStatus does
not change the result of the changesPending method. I use
resetPendingStatus(row, true) on both the dataset and storagedataset.
Makes no difference. Any ideas?

Have you tried this with JB9 or JB10? (DX has recently had some
updates)
It has been a while since I have done GUI stuff with DX so this
particular sequence is not one I have done since JB4ish (worked then as
I remember it)
Can you slap together a small demo of this?? I give it a look..
Also do one other thing, post this on qc.borland.com This will
insure that Borland "sees" the folks are using DX and having "issues".
Very important!!!
John..
--
=============================================
TeamB are volunteer helpers. Please DO NOT REPLY VIA EMAIL!
Post all questions and replies to this newsgroup ONLY
For papers on DataExpress, Applets, JSP, and Web Development go to:
www.microps.com/mps/papers.html
====================================================
 

Re:Status Bits

Neither JB8 or 10 work. Well if not DX, then what? I inherited this app,
so I'm interested in other
Borland alternatives, other than 3rd party or is there a 3rd party tool much
better? I remember Sybase DW although had it's shortcomings was much better
than the JB's dataset approach.
"John B. Moore (TeamB)" < XXXX@XXXXX.COM >wrote in message
Quote
In < XXXX@XXXXX.COM >Ted Slate wrote:
>JB8- Only one row is changed in a dataset. The row is refetched. The
>changesPending method always returns true. The resetPendingStatus does
>not change the result of the changesPending method. I use
>resetPendingStatus(row, true) on both the dataset and storagedataset.
>Makes no difference. Any ideas?
>

Have you tried this with JB9 or JB10? (DX has recently had some
updates)

It has been a while since I have done GUI stuff with DX so this
particular sequence is not one I have done since JB4ish (worked then as
I remember it)

Can you slap together a small demo of this?? I give it a look..

Also do one other thing, post this on qc.borland.com This will
insure that Borland "sees" the folks are using DX and having "issues".
Very important!!!

John..
--
=============================================
TeamB are volunteer helpers. Please DO NOT REPLY VIA EMAIL!
Post all questions and replies to this newsgroup ONLY
For papers on DataExpress, Applets, JSP, and Web Development go to:
www.microps.com/mps/papers.html
====================================================
 

{smallsort}

Re:Status Bits

Ted Slate wrote:
Quote
Neither JB8 or 10 work. Well if not DX, then what? ...
I'm guessing that you interpreted the following
quote from John's response to mean that he was using
something else.
Quote
>It has been a while since I have done GUI stuff with DX so this
>particular sequence is not one I have done since JB4ish (worked then as
>I remember it)
I think what he was saying is that he hasn't done
GUI work for a long time (he does mainly Web app
related work). Hence, his use of the DX components,
which are mainly used with GUI (desktop) apps,
diminished significantly around JB 4 or so.
(The DX components may be used on the server
side of Web apps, but there are other alternatives,
even straight JDBC. The strength of the DX components
is greatest when paired with using the dbSwing
controls, and that's entirely within the domain
of desktop, or "GUI", apps.)
Quote
>Can you slap together a small demo of this?
Can you do this for him or anyone else who has
the time to look into your problem?
Also, I found your original description is so
sparse that it's not apparent that there's a
problem. There's no question. What is it that
you are trying to do such that any of these
status indicators matter? Do you expect
them to change, and what do you expect them
to tell you?
Ted Slate wrote:
Quote
>>JB8- Only one row is changed in a dataset. The row is refetched. The
>>changesPending method always returns true. The resetPendingStatus does
>>not change the result of the changesPending method. I use
>>resetPendingStatus(row, true) on both the dataset and storagedataset.
>>Makes no difference.
"on both the dataset and storagedataset" doesn't
make sense. The former is an abstract class
and cannot be instantiated. However, it's unlikely
that you used the latter directly. More likely,
you are using a QueryDataSet or a TableDataSet.
I just did a search on the use of "resetPendingStatus()"
and "changePending()" in the "samples" folder, and
came up with four classes for the former, and just
one the latter. All appear to be related to resolvers.
--
Paul Furbacher (TeamB)
Save time, search the archives:
www.borland.com/newsgroups/ngsearch.html
Is it in Joi Ellis's Faq-O-Matic?
www.visi.com/~gyles19/fom-serve/cache/1.html
Finally, please send responses to the newsgroup only.
That means, do not send email directly to me.
Thank you.
 

Re:Status Bits

The original post lines are contained in <<>>
<<JB8- Only one row is changed in a dataset.>>
This means that only one row has changed in a fresh dataset.
<<The row is refetched.>>
This means that the changed row is refetched.
<< The changesPending method always returns true.>>
This means that the changesPending method returns true after a/the row has
been refetched.
<<The resetPendingStatus does not change the result of the changesPending
method. I use
resetPendingStatus(row, true) on both the dataset and storagedataset.>>
This means that the resetPendingStatusMethod does not change back the status
to LOADED.
<< Makes no difference. Any ideas?>>
Means that attempts are done on both dataset types because it wasn't working
and I need ideas from anyone who has done this or is trying to do it.
The status needs to be changed back to LOADED(see rowstatus interface) and
apparently, refetching the row
does not do it.
Here's some code:
// retain internal row
long intRow = jdbTable1.getDataSet().getInternalRow();
// get a copy row and put current values there
DataRow dr = new DataRow(jdbTable1.getDataSet());
jdbTable1.getDataSet().getDataRow(dr);
// put db data into current row
jdbTable1.getDataSet().refetchRow(dr);
// put current datarow into dataset
jdbTable1.getDataSet().updateRow(dr);
jdbTable1.getDataSet().resetPendingStatus(intRow, true);
The resolvers are not relevant. It's a matter of the refetchrow changing the
status automatically without intervention. Failing that I tried to use the
resetPendingStatus method which even in the resolvers doc indicates it's
supposed to change it back to LOADED. As far as what John indicated,
seemded pretty clear to me, extra explanation not neccessary.
My question to John indicated I might be interested in some good 3rd party
tool ideas because a number of senior developers are having issues with DX
as applications get larger and more complicated.
Concerns are valid since at version 8 or even 10, these types of things,
including directly manipulating status btis of a row should not be a
problem. Including
the ability to check if a row has been modified without looping through all
the columns. A common feature of any platform application no matter what
language is the ability
to decipher any changes the user has made to warn them about saving before
losing work. It's equally the same issue in the reverse, not needlessly
warning users if they haven't made any changes.
In order to do this row status access is required for grids and more
appropriate then column access.
Your comments about using which dataset don't make sense, changesPending
only exists in the storage dataset. Tabledataset is a child of storage
dataset so what's the point, storageDataset is being used regardless.
Judging by your comments apparently you either don't use refetch row, or
have not used the methods to check status for changes made. Try it out and
then let us know.
Hopefully you have some answers but it's a lot simpler if you just ask
instead of lecture. John seemed to know, and his answer was fine by me.
Thanks.
"Paul Furbacher" < XXXX@XXXXX.COM >wrote in message
Quote
Ted Slate wrote:

>Neither JB8 or 10 work. Well if not DX, then what? ...

I'm guessing that you interpreted the following
quote from John's response to mean that he was using
something else.

>>It has been a while since I have done GUI stuff with DX so this
>>particular sequence is not one I have done since JB4ish (worked then as
>>I remember it)

I think what he was saying is that he hasn't done
GUI work for a long time (he does mainly Web app
related work). Hence, his use of the DX components,
which are mainly used with GUI (desktop) apps,
diminished significantly around JB 4 or so.
(The DX components may be used on the server
side of Web apps, but there are other alternatives,
even straight JDBC. The strength of the DX components
is greatest when paired with using the dbSwing
controls, and that's entirely within the domain
of desktop, or "GUI", apps.)

>>Can you slap together a small demo of this?

Can you do this for him or anyone else who has
the time to look into your problem?

Also, I found your original description is so
sparse that it's not apparent that there's a
problem. There's no question. What is it that
you are trying to do such that any of these
status indicators matter? Do you expect
them to change, and what do you expect them
to tell you?

Ted Slate wrote:

>>>JB8- Only one row is changed in a dataset. The row is refetched.
The
>>>changesPending method always returns true. The resetPendingStatus
does
>>>not change the result of the changesPending method. I use
>>>resetPendingStatus(row, true) on both the dataset and
storagedataset.
>>>Makes no difference.

"on both the dataset and storagedataset" doesn't
make sense. The former is an abstract class
and cannot be instantiated. However, it's unlikely
that you used the latter directly. More likely,
you are using a QueryDataSet or a TableDataSet.


I just did a search on the use of "resetPendingStatus()"
and "changePending()" in the "samples" folder, and
came up with four classes for the former, and just
one the latter. All appear to be related to resolvers.


--


Paul Furbacher (TeamB)

Save time, search the archives:
www.borland.com/newsgroups/ngsearch.html

Is it in Joi Ellis's Faq-O-Matic?
www.visi.com/~gyles19/fom-serve/cache/1.html

Finally, please send responses to the newsgroup only.
That means, do not send email directly to me.
Thank you.

 

Re:Status Bits

I don't find your reply to Paul really polite.
People write to you in order to help you and you make irony?
You forgot a line. This is the working version:
// retain internal row
long intRow = jdbTable1.getDataSet().getInternalRow();
// get a copy row and put current values there
DataRow dr = new DataRow(jdbTable1.getDataSet());
jdbTable1.getDataSet().getDataRow(dr);
// put db data into current row
jdbTable1.getDataSet().refetchRow(dr);
// put current datarow into dataset
jdbTable1.getDataSet().updateRow(dr);
ProviderHelp.markPendingStatus( jdbTable1.getDataSet(), true);
jdbTable1.getDataSet().resetPendingStatus(intRow, true);
In fact resetPendingStatus RESET rows marked as PENDING_RESOLVED.
This make sense when you deal with resolving.
You can mark rows as resolved and then, only when you completed successfully the resolution, you commit transaction and only then you want reset pending status. So if something goes wrong you can rollback transaction and "rollback" the markings (i.e. clear PENDING_RESOLVED bit) without loosing your changes in dataset.
As you can see the resolvers ARE relevant. Methods markPendingStatus and resetPendingStatus are usually used in custom resolvers and you if you had had a look at resolver samples as Paul hinted you probably found it yourself.
Since who said about 2 versions of resetPendingStatus is you, what did you mean saing "Your comments about using which dataset don't make sense" ?
You created confusion, didn't you?
After seeing your code I stilll can't understand where are the 2 datasets.....
bye
Plinio
On Thu, 4 Dec 2003 08:51:32 -0500
"Ted Slate" < XXXX@XXXXX.COM >wrote:
Quote
The original post lines are contained in <<>>
<<JB8- Only one row is changed in a dataset.>>
This means that only one row has changed in a fresh dataset.

<<The row is refetched.>>
This means that the changed row is refetched.

<< The changesPending method always returns true.>>
This means that the changesPending method returns true after a/the row has
been refetched.

<<The resetPendingStatus does not change the result of the changesPending
method. I use
resetPendingStatus(row, true) on both the dataset and storagedataset.>>
This means that the resetPendingStatusMethod does not change back the status
to LOADED.

<< Makes no difference. Any ideas?>>
Means that attempts are done on both dataset types because it wasn't working
and I need ideas from anyone who has done this or is trying to do it.

The status needs to be changed back to LOADED(see rowstatus interface) and
apparently, refetching the row
does not do it.

Here's some code:

// retain internal row
long intRow = jdbTable1.getDataSet().getInternalRow();
// get a copy row and put current values there
DataRow dr = new DataRow(jdbTable1.getDataSet());
jdbTable1.getDataSet().getDataRow(dr);
// put db data into current row
jdbTable1.getDataSet().refetchRow(dr);
// put current datarow into dataset
jdbTable1.getDataSet().updateRow(dr);
jdbTable1.getDataSet().resetPendingStatus(intRow, true);

The resolvers are not relevant. It's a matter of the refetchrow changing the
status automatically without intervention. Failing that I tried to use the
resetPendingStatus method which even in the resolvers doc indicates it's
supposed to change it back to LOADED. As far as what John indicated,
seemded pretty clear to me, extra explanation not neccessary.
My question to John indicated I might be interested in some good 3rd party
tool ideas because a number of senior developers are having issues with DX
as applications get larger and more complicated.
Concerns are valid since at version 8 or even 10, these types of things,
including directly manipulating status btis of a row should not be a
problem. Including
the ability to check if a row has been modified without looping through all
the columns. A common feature of any platform application no matter what
language is the ability
to decipher any changes the user has made to warn them about saving before
losing work. It's equally the same issue in the reverse, not needlessly
warning users if they haven't made any changes.
In order to do this row status access is required for grids and more
appropriate then column access.

Your comments about using which dataset don't make sense, changesPending
only exists in the storage dataset. Tabledataset is a child of storage
dataset so what's the point, storageDataset is being used regardless.

Judging by your comments apparently you either don't use refetch row, or
have not used the methods to check status for changes made. Try it out and
then let us know.
Hopefully you have some answers but it's a lot simpler if you just ask
instead of lecture. John seemed to know, and his answer was fine by me.

Thanks.


"Paul Furbacher" < XXXX@XXXXX.COM >wrote in message
news:3fce49ce$ XXXX@XXXXX.COM ...
>Ted Slate wrote:
>
>>Neither JB8 or 10 work. Well if not DX, then what? ...
>
>I'm guessing that you interpreted the following
>quote from John's response to mean that he was using
>something else.
>
>>>It has been a while since I have done GUI stuff with DX so this
>>>particular sequence is not one I have done since JB4ish (worked then as
>>>I remember it)
>
>I think what he was saying is that he hasn't done
>GUI work for a long time (he does mainly Web app
>related work). Hence, his use of the DX components,
>which are mainly used with GUI (desktop) apps,
>diminished significantly around JB 4 or so.
>(The DX components may be used on the server
>side of Web apps, but there are other alternatives,
>even straight JDBC. The strength of the DX components
>is greatest when paired with using the dbSwing
>controls, and that's entirely within the domain
>of desktop, or "GUI", apps.)
>
>>>Can you slap together a small demo of this?
>
>Can you do this for him or anyone else who has
>the time to look into your problem?
>
>Also, I found your original description is so
>sparse that it's not apparent that there's a
>problem. There's no question. What is it that
>you are trying to do such that any of these
>status indicators matter? Do you expect
>them to change, and what do you expect them
>to tell you?
>
>Ted Slate wrote:
>
>>>>JB8- Only one row is changed in a dataset. The row is refetched.
The
>>>>changesPending method always returns true. The resetPendingStatus
does
>>>>not change the result of the changesPending method. I use
>>>>resetPendingStatus(row, true) on both the dataset and
storagedataset.
>>>>Makes no difference.
>
>"on both the dataset and storagedataset" doesn't
>make sense. The former is an abstract class
>and cannot be instantiated. However, it's unlikely
>that you used the latter directly. More likely,
>you are using a QueryDataSet or a TableDataSet.
>
>
>I just did a search on the use of "resetPendingStatus()"
>and "changePending()" in the "samples" folder, and
>came up with four classes for the former, and just
>one the latter. All appear to be related to resolvers.
>
>
>--
>
>
>Paul Furbacher (TeamB)
>
>Save time, search the archives:
>www.borland.com/newsgroups/ngsearch.html
>
>Is it in Joi Ellis's Faq-O-Matic?
>www.visi.com/~gyles19/fom-serve/cache/1.html
>
>Finally, please send responses to the newsgroup only.
>That means, do not send email directly to me.
>Thank you.
>

 

Re:Status Bits

In <3fce28b3$ XXXX@XXXXX.COM >Ted Slate wrote:
Quote
Neither JB8 or 10 work. Well if not DX, then what? I inherited this
app, so I'm interested in other Borland alternatives, other than 3rd
party or is there a 3rd party tool much better? I remember Sybase DW
although had it's shortcomings was much better than the JB's dataset
approach.
I think Plinio covered the issue for you.. You might want to go to my
website at the link below and readup on resolvers.. It IS what you are
doing with respect to the tools you are trying to use. (they are
designed to be used in both the internal DX resolvers as well as custom
resolvers).
John..
--
=============================================
TeamB are volunteer helpers. Please DO NOT REPLY VIA EMAIL!
Post all questions and replies to this newsgroup ONLY
For papers on DataExpress, Applets, JSP, and Web Development go to:
www.microps.com/mps/papers.html
====================================================
 

Re:Status Bits

In < XXXX@XXXXX.COM >Ted Slate wrote:
Quote

Judging by your comments apparently you either don't use refetch row,
or have not used the methods to check status for changes made. Try it
out and then let us know. Hopefully you have some answers but it's a
lot simpler if you just ask instead of lecture.
Your original questions were a bit vague (as I indicated) and Paul was
simply trying to get you to clarify what it was you were trying to do.
Often we have to ask more questions before there can be any answers. It
can be frustrating at both ends. Mind reading is not one of our talents..
Also keep in mind that this is all FREE help.. not good to bite the
hand that is "freely" helping you..<G>If that "help" is not on the mark
yet, then re-clarify and try again..
John..
--
=============================================
TeamB are volunteer helpers. Please DO NOT REPLY VIA EMAIL!
Post all questions and replies to this newsgroup ONLY
For papers on DataExpress, Applets, JSP, and Web Development go to:
www.microps.com/mps/papers.html
====================================================
 

Re:Status Bits

<<ProviderHelp.markPendingStatus( jdbTable1.getDataSet(), true);>>
Doesn't work.
<<you make irony?>>
The word you seek is sarcasm.
<<I don't find your reply to Paul really polite>>
I didn't find his polite either.
As a first post(regretably), I posted a clear to the point and concise
message. Further, upon being lectured on a question style I posted an ad
naseum descriptive line by line explanation plus a coding sample. Still
more lecture and there are no answers!
If a dataset is brand spanking new and the status is checked through the
changesPending() method, it will always return false. Change a row and it
will always return true.
Refetch the one changed row and it should return false - it does not.
I want to change the status bit to not changed after the row is refetched to
get the changePending method to return the proper false value. In other
words, when only one row in a dataset is changed and the same row is
refetched then the changesPending method must return false. The methods
were used lacking any other methods available. Further the so-called 2
datasets which are the same source were used because one was not working.
Clearly if these methods are not intended to change the row status, what
then?
There is a problem, refetching a row should automatically set the status
bits properly and apparently it does not. Why would resolvers help if
refetching the same row doesn't reset the status bits properly, or are you
saying that refetching a row doesn't reset the status bits, or you don't
know. In fact, according to Borlands doc, a provider would be the way to
go. However, neither should be the case(provider or resolver) since this is
not accessing a custom database and there is no need to change the standard
implementation. But go ahead and prove me wrong - use a resolver to fix it.
My guess is if anything will work it's a provider and that may be the way to
go but I'm skeptical.
The bottom line is that this is probably a bug and no ones indicated
anything to the contrary. By the way John, it's pretty hard to bite a hand
that's not feeding you.
That's the problem, got a solution, great much appreciated, otherwise the
noise level so far is meaningless.
"Plinio Conti" < XXXX@XXXXX.COM >wrote in message
Quote
I don't find your reply to Paul really polite.
People write to you in order to help you and you make irony?

You forgot a line. This is the working version:

// retain internal row
long intRow = jdbTable1.getDataSet().getInternalRow();
// get a copy row and put current values there
DataRow dr = new DataRow(jdbTable1.getDataSet());
jdbTable1.getDataSet().getDataRow(dr);
// put db data into current row
jdbTable1.getDataSet().refetchRow(dr);
// put current datarow into dataset
jdbTable1.getDataSet().updateRow(dr);
ProviderHelp.markPendingStatus( jdbTable1.getDataSet(), true);
jdbTable1.getDataSet().resetPendingStatus(intRow, true);

In fact resetPendingStatus RESET rows marked as PENDING_RESOLVED.
This make sense when you deal with resolving.
You can mark rows as resolved and then, only when you completed
successfully the resolution, you commit transaction and only then you want
reset pending status. So if something goes wrong you can rollback
transaction and "rollback" the markings (i.e. clear PENDING_RESOLVED bit)
without loosing your changes in dataset.
Quote

As you can see the resolvers ARE relevant. Methods markPendingStatus and
resetPendingStatus are usually used in custom resolvers and you if you had
had a look at resolver samples as Paul hinted you probably found it
yourself.
Quote

Since who said about 2 versions of resetPendingStatus is you, what did you
mean saing "Your comments about using which dataset don't make sense" ?
You created confusion, didn't you?
After seeing your code I stilll can't understand where are the 2
datasets.....

bye

Plinio


On Thu, 4 Dec 2003 08:51:32 -0500
"Ted Slate" < XXXX@XXXXX.COM >wrote:

>The original post lines are contained in <<>>
><<JB8- Only one row is changed in a dataset.>>
>This means that only one row has changed in a fresh dataset.

>
><<The row is refetched.>>
>This means that the changed row is refetched.

>
><< The changesPending method always returns true.>>
>This means that the changesPending method returns true after a/the row
has
>been refetched.
>
><<The resetPendingStatus does not change the result of the
changesPending
>method. I use
>resetPendingStatus(row, true) on both the dataset and storagedataset.>>
>This means that the resetPendingStatusMethod does not change back the
status
>to LOADED.
>
><< Makes no difference. Any ideas?>>
>Means that attempts are done on both dataset types because it wasn't
working
>and I need ideas from anyone who has done this or is trying to do it.



>
>The status needs to be changed back to LOADED(see rowstatus interface)
and
>apparently, refetching the row
>does not do it.
>
>Here's some code:
>
>// retain internal row
>long intRow = jdbTable1.getDataSet().getInternalRow();
>// get a copy row and put current values there
>DataRow dr = new DataRow(jdbTable1.getDataSet());
>jdbTable1.getDataSet().getDataRow(dr);
>// put db data into current row
>jdbTable1.getDataSet().refetchRow(dr);
>// put current datarow into dataset
>jdbTable1.getDataSet().updateRow(dr);
>jdbTable1.getDataSet().resetPendingStatus(intRow, true);
>
>The resolvers are not relevant. It's a matter of the refetchrow changing
the
>status automatically without intervention. Failing that I tried to use
the
>resetPendingStatus method which even in the resolvers doc indicates it's
>supposed to change it back to LOADED. As far as what John indicated,
>seemded pretty clear to me, extra explanation not neccessary.
>My question to John indicated I might be interested in some good 3rd
party
>tool ideas because a number of senior developers are having issues with
DX
>as applications get larger and more complicated.
>Concerns are valid since at version 8 or even 10, these types of things,
>including directly manipulating status btis of a row should not be a
>problem. Including
>the ability to check if a row has been modified without looping through
all
>the columns. A common feature of any platform application no matter
what
>language is the ability
>to decipher any changes the user has made to warn them about saving
before
>losing work. It's equally the same issue in the reverse, not
needlessly
>warning users if they haven't made any changes.
>In order to do this row status access is required for grids and more
>appropriate then column access.
>
>Your comments about using which dataset don't make sense, changesPending
>only exists in the storage dataset. Tabledataset is a child of storage
>dataset so what's the point, storageDataset is being used regardless.
>
>Judging by your comments apparently you either don't use refetch row, or
>have not used the methods to check status for changes made. Try it out
and
>then let us know.
>Hopefully you have some answers but it's a lot simpler if you just ask
>instead of lecture. John seemed to know, and his answer was fine by me.
>
>Thanks.
>
>
>"Paul Furbacher" < XXXX@XXXXX.COM >wrote in message
>news:3fce49ce$ XXXX@XXXXX.COM ...
>>Ted Slate wrote:
>>
>>>Neither JB8 or 10 work. Well if not DX, then what? ...
>>
>>I'm guessing that you interpreted the following
>>quote from John's response to mean that he was using
>>something else.
>>
>>>>It has been a while since I have done GUI stuff with DX so this
>>>>particular sequence is not one I have done since JB4ish (worked
then as
>>>>I remember it)
>>
>>I think what he was saying is that he hasn't done
>>GUI work for a long time (he does mainly Web app
>>related work). Hence, his use of the DX components,
>>which are mainly used with GUI (desktop) apps,
>>diminished significantly around JB 4 or so.
>>(The DX components may be used on the server
>>side of Web apps, but there are other alternatives,
>>even straight JDBC. The strength of the DX components
>>is greatest when paired with using the dbSwing
>>controls, and that's entirely within the domain
>>of desktop, or "GUI", apps.)
>>
>>>>Can you slap together a small demo of this?
>>
>>Can you do this for him or anyone else who has
>>the time to look into your problem?
>>
>>Also, I found your original description is so
>>sparse that it's not apparent that there's a
>>problem. There's no question. What is it that
>>you are trying to do such that any of these
>>status indicators matter? Do you expect
>>them to change, and what do you expect them
>>to tell you?
>>
>>Ted Slate wrote:
>>
>>>>>JB8- Only one row is changed in a dataset. The row is
refetched.
>The
>>>>>changesPending method always returns true. The
resetPendingStatus
>does
>>>>>not change the result of the changesPending method. I use
>>>>>resetPendingStatus(row, true) on both the dataset and
>storagedataset.
>>>>>Makes no difference.
>>
>>"on both the dataset and storagedataset" doesn't
>>make sense. The former is an abstract class
>>and cannot be instantiated. However, it's unlikely
>>that you used the latter directly. More likely,
>>you are using a QueryDataSet or a TableDataSet.
>>
>>
>>I just did a search on the use of "resetPendingStatus()"
>>and "changePending()" in the "samples" folder, and
>>came up with four classes for the former, and just
>>one the latter. All appear to be related to resolvers.
>>
>>
>>--
>>
>>
>>Paul Furbacher (TeamB)
>>
>>Save time, search the archives:
>>www.borland.com/newsgroups/ngsearch.html
>>
>>Is it in Joi Ellis's Faq-O-Matic?
>>www.visi.com/~gyles19/fom-serve/cache/1.html
>>
>>Finally, please send responses to the newsgroup only.
>>That means, do not send email directly to me.
>>Thank you.
>>
>


 

Re:Status Bits

In <3fd71f83$ XXXX@XXXXX.COM >Ted Slate wrote:
Quote

That's the problem, got a solution, great much appreciated, otherwise
the noise level so far is meaningless.
If you have hammer, everything is a nail. That does not mean it "is"
a nail.
Your expectations of how is should work is not how it was designed to
work. This is what has been explained.
Sorry if this is not helpful.. I don't have the bandwidth to argue
whether this is right or wrong... I suggest you post your concerns to
qc.borland.com.
John..
--
=============================================
TeamB are volunteer helpers. Please DO NOT REPLY VIA EMAIL!
Post all questions and replies to this newsgroup ONLY
For papers on DataExpress, Applets, JSP, and Web Development go to:
www.microps.com/mps/papers.html
====================================================
 

Re:Status Bits

Wonderfull, my server let me see the post only today!
I have no intention to pay tributes to the god of the arguments, so I will say only about the programming fact:
I ordinary use the code:
long intRow = dataset.getInternalRow();
DataRow dr = new DataRow(dataset);
dataset.getDataRow(dr);
dataset.refetchRow(dr);
dataset.updateRow(dr);
- -->ProviderHelp.markPendingStatus( dataset, true); <--- NOTE THIS LINE
dataset.resetPendingStatus(intRow, true);
and it does work. Exactly in the sense you mean and to do exactly the same.
refetchRow down NOT have the semantic YOU expect. It does not update the current row in the dataset with a refetched version. It simply put the refetched row in the DataRow parameter.
Plinio
On Wed, 10 Dec 2003 08:28:58 -0500
"Ted Slate" < XXXX@XXXXX.COM >wrote:
Quote
<<ProviderHelp.markPendingStatus( jdbTable1.getDataSet(), true);>>
Doesn't work.
<<you make irony?>>
The word you seek is sarcasm.
<<I don't find your reply to Paul really polite>>
I didn't find his polite either.

As a first post(regretably), I posted a clear to the point and concise
message. Further, upon being lectured on a question style I posted an ad
naseum descriptive line by line explanation plus a coding sample. Still
more lecture and there are no answers!

If a dataset is brand spanking new and the status is checked through the
changesPending() method, it will always return false. Change a row and it
will always return true.
Refetch the one changed row and it should return false - it does not.

I want to change the status bit to not changed after the row is refetched to
get the changePending method to return the proper false value. In other
words, when only one row in a dataset is changed and the same row is
refetched then the changesPending method must return false. The methods
were used lacking any other methods available. Further the so-called 2
datasets which are the same source were used because one was not working.
Clearly if these methods are not intended to change the row status, what
then?

There is a problem, refetching a row should automatically set the status
bits properly and apparently it does not. Why would resolvers help if
refetching the same row doesn't reset the status bits properly, or are you
saying that refetching a row doesn't reset the status bits, or you don't
know. In fact, according to Borlands doc, a provider would be the way to
go. However, neither should be the case(provider or resolver) since this is
not accessing a custom database and there is no need to change the standard
implementation. But go ahead and prove me wrong - use a resolver to fix it.
My guess is if anything will work it's a provider and that may be the way to
go but I'm skeptical.

The bottom line is that this is probably a bug and no ones indicated
anything to the contrary. By the way John, it's pretty hard to bite a hand
that's not feeding you.

That's the problem, got a solution, great much appreciated, otherwise the
noise level so far is meaningless.


"Plinio Conti" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>I don't find your reply to Paul really polite.
>People write to you in order to help you and you make irony?
>
>You forgot a line. This is the working version:
>
>// retain internal row
>long intRow = jdbTable1.getDataSet().getInternalRow();
>// get a copy row and put current values there
>DataRow dr = new DataRow(jdbTable1.getDataSet());
>jdbTable1.getDataSet().getDataRow(dr);
>// put db data into current row
>jdbTable1.getDataSet().refetchRow(dr);
>// put current datarow into dataset
>jdbTable1.getDataSet().updateRow(dr);
>ProviderHelp.markPendingStatus( jdbTable1.getDataSet(), true);
>jdbTable1.getDataSet().resetPendingStatus(intRow, true);
>
>In fact resetPendingStatus RESET rows marked as PENDING_RESOLVED.
>This make sense when you deal with resolving.
>You can mark rows as resolved and then, only when you completed
successfully the resolution, you commit transaction and only then you want
reset pending status. So if something goes wrong you can rollback
transaction and "rollback" the markings (i.e. clear PENDING_RESOLVED bit)
without loosing your changes in dataset.
>
>As you can see the resolvers ARE relevant. Methods markPendingStatus and
resetPendingStatus are usually used in custom resolvers and you if you had
had a look at resolver samples as Paul hinted you probably found it
yourself.
>
>Since who said about 2 versions of resetPendingStatus is you, what did you
mean saing "Your comments about using which dataset don't make sense" ?
>You created confusion, didn't you?
>After seeing your code I stilll can't understand where are the 2
datasets.....
>
>bye
>
>Plinio
>
>
>On Thu, 4 Dec 2003 08:51:32 -0500
>"Ted Slate" < XXXX@XXXXX.COM >wrote:
>
>>The original post lines are contained in <<>>
>><<JB8- Only one row is changed in a dataset.>>
>>This means that only one row has changed in a fresh dataset.
>
>>
>><<The row is refetched.>>
>>This means that the changed row is refetched.
>
>>
>><< The changesPending method always returns true.>>
>>This means that the changesPending method returns true after a/the row
has
>>been refetched.
>>
>><<The resetPendingStatus does not change the result of the
changesPending
>>method. I use
>>resetPendingStatus(row, true) on both the dataset and storagedataset.>>
>>This means that the resetPendingStatusMethod does not change back the
status
>>to LOADED.
>>
>><< Makes no difference. Any ideas?>>
>>Means that attempts are done on both dataset types because it wasn't
working
>>and I need ideas from anyone who has done this or is trying to do it.
>
>
>
>>
>>The status needs to be changed back to LOADED(see rowstatus interface)
and
>>apparently, refetching the row
>>does not do it.
>>
>>Here's some code:
>>
>>// retain internal row
>>long intRow = jdbTable1.getDataSet().getInternalRow();
>>// get a copy row and put current values there
>>DataRow dr = new DataRow(jdbTable1.getDataSet());
>>jdbTable1.getDataSet().getDataRow(dr);
>>// put db data into current row
>>jdbTable1.getDataSet().refetchRow(dr);
>>// put current datarow into dataset
>>jdbTable1.getDataSet().updateRow(dr);
>>jdbTable1.getDataSet().resetPendingStatus(intRow, true);
>>
>>The resolvers are not relevant. It's a matter of the refetchrow changing
the
>>status automatically without intervention. Failing that I tried to use
the
>>resetPendingStatus method which even in the resolvers doc indicates it's
>>supposed to change it back to LOADED. As far as what John indicated,
>>seemded pretty clear to me, extra explanation not neccessary.
>>My question to John indicated I might be interested in some good 3rd
party
>>tool ideas because a number of senior developers are having issues with
DX
>>as applications get larger and more complicated.
>>Concerns are valid since at version 8 or even 10, these types of things,
>>including directly manipulating status btis of a row should not be a
>>problem. Including
>>the ability to check if a row has been modified without looping through
all
>>the columns. A common feature of any platform application no matter
what
>>language is the ability
>>to decipher any changes the user has made to warn them about saving
before
>>losing work. It's equally the same issue in the reverse, not
needlessly
>>warning users if they haven't made any changes.
>>In order to do this row status access is required for grids and more
>>appropriate then column access.
>>
>>Your comments about using which dataset don't make sense, changesPending
>>only exists in the storage dataset. Tabledataset is a child of storage
>>dataset so what's the point, storageDataset is being used regardless.
>>
>>Judging by your comments apparently you either don't use refetch row, or
>>have not used the methods to check status for changes made. Try it out
and
>>then let us know.
>>Hopefully you have some answers but it's a lot simpler if you just ask
>>instead of lecture. John seemed to know, and his answer was fine by me.
>>
>>Thanks.
>>
>>
>>"Paul Furbacher" < XXXX@XXXXX.COM >wrote in message
>>news:3fce49ce$ XXXX@XXXXX.COM ...
>>>Ted Slate wrote:
>>>
>>>>Neither JB8 or 10 work. Well if not DX, then what? ...
>>>
>>>I'm guessing that you interpreted the following
>>>quote from John's response to mean that he was using
>>>something else.
>>>
>>>>>It has been a while since I have done GUI stuff with DX so this
>>>>>particular sequence is not one I have done since JB4ish (worked
then as
>>>>>I remember it)
>>>
>>>I think what he was saying is that he hasn't done
>>>GUI work for a long time (he does mainly Web app
>>>related work). Hence, his use of the DX components,
>>>which are mainly used with GUI (desktop) apps,
>>>diminished significantly around JB 4 or so.
>>>(The DX components may be used on the server
>>>side of Web apps, but there are other alternatives,
>>>even straight JDBC. The strength of the DX components
>>>is greatest when paired with using the dbSwing
>>>controls, and that's entirely within the domain
>>>of desktop, or "GUI", apps.)
>>>
>>>>>Can you slap together a small demo of this?
>>>
>>>Can you do this for him or anyone else who has
>>>the time to look into your problem?
>>>
>>>Also, I found your original description is so
>>>sparse that it's not apparent that there's a
>>>problem. There's no question. What is it that
>>>you are trying to do such that any of these
>>>status indicators matter? Do you expect
>>>them to change, and what do you expect them
>>>to tell you?
>>>
>>>Ted Slate wrote:
>>>
>>>>>>JB8- Only one row is changed in a dataset. The row is
refetched.
>>The
>>>>>>changesPending method always returns true. The
resetPendingStatus
>>does
>>>>>>not change the result of the changesPending method. I use
>>>>>>resetPendingStatus(row, true) on both the dataset and
>>storagedataset.
>>>>>>Makes no difference.
>>>
>>>"on both the dataset and storagedataset" doesn't
>>>make sense. The former is an abstract class
>>>and cannot be instantiated. However, it's unlikely
>>>that you used the latter directly. More likely,
>>>you are using a QueryDataSet or a TableDataSet.
>>>
>>>
>>>I just did a search on the use of "resetPendingStatus()"
>>>and "changePending()" in the "samples" folder, and
>>>came up with four classes for the former, and just
>>>one the latter. All appear to be related to resolvers.
>>>
>>>
>>>--
>>>
>>>
>>>Paul Furbacher (TeamB)
>>>
>>>Save time, search the archives:
>>>www.borland.com/newsgroups/ngsearch.html
>>>
>>>Is it in Joi Ellis's Faq-O-Matic?
>>>www.visi.com/~gyles19/fom-serve/cache/1.html
>>>
>>>Finally, please send responses to the newsgroup only.
>>>That means, do not send email directly to me.
>>>Thank you.
>>>
>>
>
>