🚀 go-pugleaf

Hi James,

> I am trying to use a datagrid control and enable paging. No matter what I do I get the following errror: 
> Invalid CurrentPageIndex value. It must be >= 0 and < the PageCount.
> even though if I step through and debug I see that the pageindex I am attempting to set (1) is less than the page count (2). 

But when you call DataBind on the DataGrid again, does the DataGrid's 
DataSource still contain the data? Did you re-execute the query, or 
obtain the data from a cache (like the session for example?).

Note that if you use BdpDataAdapter, then leaving the Active property 
set to True will do the trick (it's not as efficient as storing the 
result in the session, but at least ensures the query will always be 
re-executed).

> I have searched for this message in the newsgroups and cannot find any answer that applies. Has anyone had this problem and been able to resolve it? 

See 
http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0401swart/ 
for an example how to do it using BdpDataAdapter.

> Thanks,
> James

Groetjes,
           Bob Swart

-- 
Bob Swart Training & Consultancy (eBob42.com)  Forever Loyal to Delphi
Blog: http://www.drbob42.com/blog - RSS: http://drbob42.com/weblog.xml
New Delphi 2006 Courseware e-books at http://www.eBob42.com/courseware

Hello Bob,

I managed to get it to work but what I had to do was the following:

      DataSet1.Dispose;
      DataSet1 := Dataset.Create;
      lItemCount := daRequests.Fill(Dataset1);

which seems really inefficient since it implies that on each Pageindex
change I go and get all the data again. I guess I just don't understand
these objects because it seemed to me that once I had used the Fill() the
data should be available in the dataset so that any requests such as for a
different page index would simply use whatever was in the dataset at the
time the request was made.

I am not using the BDP objects but rather the OLEDB objects. Is there any
particular reason to use one over the other?

I will check the reference you posted - thank you for that! And I would also
like to offer a general thanks to you for your generosity in giving your
time and sharing your knowledge in these group postings! I have learned a
lot from many of your answers to others and postings and I can't thank you
enough for that!!!

James


"Bob Swart" <b.swart@chello.nl> wrote in message
news:45A0CBC6.4090602@chello.nl...
> Hi James,
>
> > I am trying to use a datagrid control and enable paging. No matter what
I do I get the following errror:
> > Invalid CurrentPageIndex value. It must be >= 0 and < the PageCount.
> > even though if I step through and debug I see that the pageindex I am
attempting to set (1) is less than the page count (2).
>
> But when you call DataBind on the DataGrid again, does the DataGrid's
> DataSource still contain the data? Did you re-execute the query, or
> obtain the data from a cache (like the session for example?).
>
> Note that if you use BdpDataAdapter, then leaving the Active property
> set to True will do the trick (it's not as efficient as storing the
> result in the session, but at least ensures the query will always be
> re-executed).
>
> > I have searched for this message in the newsgroups and cannot find any
answer that applies. Has anyone had this problem and been able to resolve
it?
>
> See
>
http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0401swart/
> for an example how to do it using BdpDataAdapter.
>
> > Thanks,
> > James
>
> Groetjes,
>            Bob Swart
>
> -- 
> Bob Swart Training & Consultancy (eBob42.com)  Forever Loyal to Delphi
> Blog: http://www.drbob42.com/blog - RSS: http://drbob42.com/weblog.xml
> New Delphi 2006 Courseware e-books at http://www.eBob42.com/courseware

James D. Franchello wrote:

> Hello Bob,
> 
> I managed to get it to work but what I had to do was the following:
> 
>       DataSet1.Dispose;
>       DataSet1 := Dataset.Create;
>       lItemCount := daRequests.Fill(Dataset1);
> 
> which seems really inefficient since it implies that on each Pageindex

Then you don't understand how WEB applications work.

This analogy works, albeit, extremely oversimplified:

- Take into mind a Win32 application.
- When you request a Web Page, the application is started.
- When the web page is rendered the application is terminated.

Thus anything created is also destroyed immediately.

> change I go and get all the data again. I guess I just don't
> understand these objects because it seemed to me that once I had used
> the Fill() the data should be available in the dataset so that any

Not in the dataset itself, because the object is destroyed because the
application is terminated.

You would need to store it into the viewstate of the webpage, and in
the repost would need to retreive it from there.

But you don't want that. Pages like these get gargantuan in size real
quick and you don't want to have your visitors waiting 2 minutes on
every repost before they see the new page.

> I am not using the BDP objects but rather the OLEDB objects. Is there
> any particular reason to use one over the other?

What database do you have? Does BDP support your database? If not, use
OLEDB.
BDP == Larger overhead, but better designtime support IF you've got a
higher than PRO SKU. PRO and below (turbo's) and BDP's useless anyways
as you can't bind it to anything because they didn't bother to put in
the components required to do so.

Hello Marco,

Thanks for your kind response - I do understand it a little better now (you
were absolutely right about my understanding of Web apps ... sadly ...
sigh...).

I guess the thing I just could not wrap my mind around was the fact that if
a request involved, oh, let's say hundreds of records, and they were paged
10 at a time then each time I wanted to get the next 10 (or prior for that
matter) I would have to go get those hundreds of records again. Once you
pointed out the utterly obvious about the dataset it makes a lot more sense!

This application is currently using an Access database but may at some point
be converted to SQL server. It will only be used in a single manufacturing
facility on the server on the LAN.

Actually, I am using the Enterprise version.

I did manage to get things working with OLEDB. Now I am trying to deal with
how to deploy it (what files need to go where and what access rights have to
be assigned).

Thanks again,
James


"Marco Caspers" <HexorHaxor@vaxor.com> wrote in message
news:45a33994@newsgroups.borland.com...
> James D. Franchello wrote:
>
> > Hello Bob,
> >
> > I managed to get it to work but what I had to do was the following:
> >
> >       DataSet1.Dispose;
> >       DataSet1 := Dataset.Create;
> >       lItemCount := daRequests.Fill(Dataset1);
> >
> > which seems really inefficient since it implies that on each Pageindex
>
> Then you don't understand how WEB applications work.
>
> This analogy works, albeit, extremely oversimplified:
>
> - Take into mind a Win32 application.
> - When you request a Web Page, the application is started.
> - When the web page is rendered the application is terminated.
>
> Thus anything created is also destroyed immediately.
>
> > change I go and get all the data again. I guess I just don't
> > understand these objects because it seemed to me that once I had used
> > the Fill() the data should be available in the dataset so that any
>
> Not in the dataset itself, because the object is destroyed because the
> application is terminated.
>
> You would need to store it into the viewstate of the webpage, and in
> the repost would need to retreive it from there.
>
> But you don't want that. Pages like these get gargantuan in size real
> quick and you don't want to have your visitors waiting 2 minutes on
> every repost before they see the new page.
>
> > I am not using the BDP objects but rather the OLEDB objects. Is there
> > any particular reason to use one over the other?
>
> What database do you have? Does BDP support your database? If not, use
> OLEDB.
> BDP == Larger overhead, but better designtime support IF you've got a
> higher than PRO SKU. PRO and below (turbo's) and BDP's useless anyways
> as you can't bind it to anything because they didn't bother to put in
> the components required to do so.

James D. Franchello wrote:

> Hello Marco,
> 
> Thanks for your kind response - I do understand it a little better
> now (you were absolutely right about my understanding of Web apps ...
> sadly ...  sigh...).
<snip>

Well it was kinda blunt of me to put it that way, soz for that.
Viewstate isn't the only way to store the dataset, you could also use
the session state. That's a server side object you can put pretty much
anything you like in. But you have to remember that that solution eats
lots of memory on your webserver.

 
> This application is currently using an Access database but may at
> some point be converted to SQL server. It will only be used in a
> single manufacturing facility on the server on the LAN.

Take into consideration to use MySQL.
MySQL has an internal paging mechanism that allows you to get a
specific "window" of records from a SELECT query.

> Actually, I am using the Enterprise version.
Nice, too expensive for myself tho, i'm not making lots of money with
programming, it's more of a hobby for me. I have another full time day
job to make a living..
 
> I did manage to get things working with OLEDB. 

> Now I am trying to deal with how to deploy it (what files need to go
> where and what access rights have to be assigned).

ASP.NET user is the user you need to assign to the directories you
deploy to.
You need to deploy at least Borland.Delphi.dll and any other
non-microsoft dll that's mentioned in the references list of the
project.

But i.i.r.c. from the Enterprise demo i tried, the Enterprise SKU comes
with a deployment tool that creates a bdsdeploy file, whith the tool
you can deploy anything from the project that's required to run it
properly.

> <snip>
>
> Well it was kinda blunt of me to put it that way, soz for that.

No offense taken!

> Viewstate isn't the only way to store the dataset, you could also use
> the session state. That's a server side object you can put pretty much
> anything you like in. But you have to remember that that solution eats
> lots of memory on your webserver.

I will definitely keep this in mind. I guess this is where the trade-offs
start coming in to play as to whether one keeps a dataset in a view state,
session state, or simply requery the database. So far I have only kept small
items in the session state (like a numeric key - int64). That seems not to
be too imposing but perhaps there is a good bit more overhead in just doing
that than I suspect. Is there any method of predicting the size of the
memory that is consumed by session state info?

<snip>

> Take into consideration to use MySQL.
> MySQL has an internal paging mechanism that allows you to get a
> specific "window" of records from a SELECT query.
>

I have not used MySQL but this sounds interesting - I will look in to it -
thanks!

> > Actually, I am using the Enterprise version.
> Nice, too expensive for myself tho, i'm not making lots of money with
> programming, it's more of a hobby for me. I have another full time day
> job to make a living..
>

Well, ... if it had to come out of my pocket personally ...
You do this as a hobby? Now I feel really bad about taking your up time  -
and - that much more grateful for your generous contributions to these
newsgroups - my great thanks again!

>
> ASP.NET user is the user you need to assign to the directories you
> deploy to.
> You need to deploy at least Borland.Delphi.dll and any other
> non-microsoft dll that's mentioned in the references list of the
> project.
>

more good tips!

> But i.i.r.c. from the Enterprise demo i tried, the Enterprise SKU comes
> with a deployment tool that creates a bdsdeploy file, whith the tool
> you can deploy anything from the project that's required to run it
> properly.

I have seen it and started to 'play' with it ... do you get the feeling that
I am just a slow learner????

Many thanks again!
James