| Subject | Re: [IBO] Cached Updates? |
|---|---|
| Author | Lee Jenkins |
| Post date | 2003-12-08T04:09Z |
Helen Borrie wrote:
per se, I have used kbmMemTable to cache data up until this point for
this particular (restaurant point of sale) application. Granted, the
biggest reason I've used memory tables is because much of the
information is static like food menus, discounts, etc. This type of
data is all loaded into memory tables when the application starts up.
By reducing the amount of reads from the database (and thus network
trips) screen transitions are very, very fast and perceived speed is
very nice.
I've also always thought that using cached updates in the form of memory
tables for the Sale (header table) and Items (Line Items) tables was
more efficient overall as well. From my experience, a POS application
like mine is much different than a typical desktop application because
there is not a lot of browsing of data, scrolling through result sets,
etc. Its mostly, log on, enter quick data (though touch screen
interface), prompt the user to save changes and jam the updates/inserts
into the backend db in a single transaction. After that, the user
typically logs out (or is logged out after x minutes of no activity).
Issues with multiple users trying to update data at the same time is not
and issue because in restaurants, most of the data is unique to an
individual user such as sales.
Actually, now that I think about it, much of the reason for the way that
I do things with this particular application stems from fact that we
used to use an Access DB for the backend where my goal was always to
have resultsets opened the VERY least amount of time as possible. Also
seemed like good sense to cram UPDATES/INSERTS in one fast transaction
as opposed to having more and frequent updates/inserts with that kind of
backend. (Sure am glad IB went open source ;)).
I've only been using IB/Firebird for a little over 2 years now so I'm
still suffering from CDS (thats Clue Difficiency Syndrome) and
especially so with IBO so if you can offer any tips or suggestions, I'm
always open to improvement. :)
--
Warm Regards,
Lee
> At 09:08 PM 7/12/2003 -0500, you wrote:Good Question. Mostly habit, I guess. I have never used CachedUpdates
>
>>Helen Borrie wrote:
>>
>>>At 12:29 PM 7/12/2003 -0500, you wrote:
>>>
>>>
>>>
>>>>Hi, where can I find more information on using CachedUpdates with
>>>>IBODataset?
>>>
>>>
>>>In the Delphi help. Substitute a TUpdateSQL with a TIBOUpdateSQL. It's
>>>not an IBO-particular thing.
>>>
>>>Helen
>>
>>One other question; Doesn't TIBODataset already have an implicit
>>UpdateSQL somewhat like IBX's TIBDataset?
>
>
> It has the update properties EditSQL, InsertSQL and DeleteSQL, yes, same
> function. When you asked about CachedUpdates it wasn't clear you didn't
> know anything about them...TIBOUpdateSQL is only there for compatibility
> for converting.
>
> Sort-of wondering why you want to do CachedUpdates with IBO anyway...but
> don't have time to get into a debate about it. Nuff to say that, pre-IBO
> days, I used to use CachedUpdates to get an "updatable" dataset from a
> query. With all the built-in stuff in IBO, there's no need for it unless
> you are using some other (external) architecture that requires it for some
> other reason.
>
> Helen
per se, I have used kbmMemTable to cache data up until this point for
this particular (restaurant point of sale) application. Granted, the
biggest reason I've used memory tables is because much of the
information is static like food menus, discounts, etc. This type of
data is all loaded into memory tables when the application starts up.
By reducing the amount of reads from the database (and thus network
trips) screen transitions are very, very fast and perceived speed is
very nice.
I've also always thought that using cached updates in the form of memory
tables for the Sale (header table) and Items (Line Items) tables was
more efficient overall as well. From my experience, a POS application
like mine is much different than a typical desktop application because
there is not a lot of browsing of data, scrolling through result sets,
etc. Its mostly, log on, enter quick data (though touch screen
interface), prompt the user to save changes and jam the updates/inserts
into the backend db in a single transaction. After that, the user
typically logs out (or is logged out after x minutes of no activity).
Issues with multiple users trying to update data at the same time is not
and issue because in restaurants, most of the data is unique to an
individual user such as sales.
Actually, now that I think about it, much of the reason for the way that
I do things with this particular application stems from fact that we
used to use an Access DB for the backend where my goal was always to
have resultsets opened the VERY least amount of time as possible. Also
seemed like good sense to cram UPDATES/INSERTS in one fast transaction
as opposed to having more and frequent updates/inserts with that kind of
backend. (Sure am glad IB went open source ;)).
I've only been using IB/Firebird for a little over 2 years now so I'm
still suffering from CDS (thats Clue Difficiency Syndrome) and
especially so with IBO so if you can offer any tips or suggestions, I'm
always open to improvement. :)
--
Warm Regards,
Lee