# How to use BUFFER()?

**URL:** <https://clarionhub.com/t/how-to-use-buffer/8854>\
**Category:** questions\
**Tags:** sql, browse\
**Created:** [December 13, 2025, 2:19pm UTC](https://clarionhub.com/t/how-to-use-buffer/8854 "2025-12-13T14:19:28Z")\
**Posts on this page:** 8\
**Page:** 2

<div class="post-metadata">

**Author:** ![Koen](https://clarionhub.com/letter_avatar_proxy/v4/letter/k/a9a28c/32.png) [@Koen](https://clarionhub.com/u/Koen)\
**Post date:** [December 16, 2025, 7:03pm UTC](https://clarionhub.com/t/how-to-use-buffer/8854/21 "2025-12-16T19:03:32Z")

</div>

> [@JonW](#):
>
> … and send new queries all the time (though with bind variables) each time you need a new page of data.

At that is what I would like to prevent. Right now it takes time to fill the browse. But once loaded scrolling up and down is fast enough. What annoys me is that resizing the window triggers a reload.Normally that is good because you can be sure the data is up to date. But is this case it probably won’t be changed.

The real answer is probably that convince the users to start with a smaller date range.

---

<div class="post-metadata">

**Author:** ![Koen](https://clarionhub.com/letter_avatar_proxy/v4/letter/k/a9a28c/32.png) [@Koen](https://clarionhub.com/u/Koen)\
**Post date:** [December 16, 2025, 7:09pm UTC](https://clarionhub.com/t/how-to-use-buffer/8854/22 "2025-12-16T19:09:20Z")

</div>

> [@Bruce](#):
>
> Creating a cursor takes time. I dont think SSMS creates a cursor. Thus it can start displaying records immediately.

OK, that clarifies why loading in MS SQL Management Studio is faster compared by loading in the browse.

> [@Bruce](#):
>
> BUFFER cannot help speed up the cursor creation because creating a cursor is a server function. It _can_ help in moving the data to the client, but that’s not what is causing the delay you are seeing.

Thanks for this clarification. Using BUFFER wil not help me in this case.

---

<div class="post-metadata">

**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\
**Post date:** [December 16, 2025, 7:15pm UTC](https://clarionhub.com/t/how-to-use-buffer/8854/23 "2025-12-16T19:15:58Z")

</div>

> [@Koen](#):
>
> The real answer is probably that convince the users to start with a smaller date range.

Yes, a good approach with the old driver is to make the default of the browse filter to a limited result set (assuming a good key for the filter).

In the long run I think switching to the (very expensive) new driver is going to become the norm for serious/commercial programs. It allows programs to be fundamentally better, without any code changes. It is expensive, but ultimately the value dwarfs the price.

---

<div class="post-metadata">

**Author:** ![Koen](https://clarionhub.com/letter_avatar_proxy/v4/letter/k/a9a28c/32.png) [@Koen](https://clarionhub.com/u/Koen)\
**Post date:** [December 16, 2025, 7:24pm UTC](https://clarionhub.com/t/how-to-use-buffer/8854/24 "2025-12-16T19:24:26Z")

</div>

> [@seanh](#):
>
> I’ve had great success with reports using forward buffers and no back buffers. Speeds things a lot.
> 
> None of this helps build the query in the first place as Bruce and Jon, et cetra explained

True this won’t work in this particular browse that is very clear now. But what you are saying when using is for reports is interesting. I think I can use the same trick for looping over a view.  
Thank you for this clarification.

---

<div class="post-metadata">

**Author:** ![Koen](https://clarionhub.com/letter_avatar_proxy/v4/letter/k/a9a28c/32.png) [@Koen](https://clarionhub.com/u/Koen)\
**Post date:** [December 16, 2025, 7:40pm UTC](https://clarionhub.com/t/how-to-use-buffer/8854/25 "2025-12-16T19:40:03Z")

</div>

> [@Bruce](#):
>
> I don’t think there’s any way to tell the old driver to behave like that. Although, thinking about it, it may not be the driver that controls that, as much as the template controls that

Maybe I can figure an easier way: In WM.TakeResize it mus be possible to prevent reloading some way.

However I am getting very curious on your new SQL driver. Based on what you are telling it will have great advantages.

Is it possible to mix the new and old driver in the same dictionary? Or to be more precise: Can I have a SQL side view which uses the new driver in the dictionary while the real tables still use the old driver?

If so that would be great, because the large data set I am talking about here comes from a complex SQL side view (several joins, sub queries and a Union).

---

<div class="post-metadata">

**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\
**Post date:** [December 16, 2025, 9:43pm UTC](https://clarionhub.com/t/how-to-use-buffer/8854/26 "2025-12-16T21:43:53Z")

</div>

Yes you can mix drivers in the same dict. Just like you can mix say SQL and TPS drivers.

Your understanding of a “server side view” however is incomplete. You’re thinking of it as a pre-formed result set on the server. Its common for Clarion people ro think in this way.

In fact its nothing more than a SQL SELECT statement. Whether it is pre-stored in the server, or sent from the client on each use, is the same. In both cases the server builds the result set “on demand”. It is not pre-calculated. There is no performance gained by it being a “server side view”.

As mentioned earlier, any sql can be sent to the server via the SQL command.

I’d also add that while you can mix drivers, you won’t. Once you gave the new driver you’ll use it for all your tables - there simply would be no point in not doing that.

---

<div class="post-metadata">

**Author:** ![Koen](https://clarionhub.com/letter_avatar_proxy/v4/letter/k/a9a28c/32.png) [@Koen](https://clarionhub.com/u/Koen)\
**Post date:** [December 16, 2025, 10:06pm UTC](https://clarionhub.com/t/how-to-use-buffer/8854/27 "2025-12-16T22:06:00Z")

</div>

> [@Bruce](#):
>
> Your understanding of a “server side view” however is incomplete. You’re thinking of it as a pre-formed result set on the server. Its common for Clarion people ro think in this way.

I know it is just a SQL statement and certainly not a result set.

But the advantage to have a view defined on the server is that you add that view in the dictionary as if it is a table. The Clarion templates see it then as a normal table making it is possible to use it for example in the browse template.

---

<div class="post-metadata">

**Author:** ![Omar\_Squiabro](https://clarionhub.com/user_avatar/clarionhub.com/omar_squiabro/32/4474_2.png) [@Omar\_Squiabro](https://clarionhub.com/u/Omar_Squiabro)\
**Post date:** [December 19, 2025, 11:21am UTC](https://clarionhub.com/t/how-to-use-buffer/8854/28 "2025-12-19T11:21:28Z")

</div>

If your tables is for read only go to global properties, action, individual file overrides and change the file open mode to read only and the cursor don’t is created, i always uses complex server side views and import to dct with a real big database and the response is impresive

[Previous page](https://clarionhub.com/t/how-to-use-buffer/8854.md?page=1)
