(Oops-I originally posted in the dbISAM newsgroup by mistake so here it
is in the correct NG)

I see the table buffers still can't be increased in size. I tried to
make the Maximum Row Buffer/Index Buffer Pool Size and as soon as I
pressed "Ok" button, it closes the EdbMgr, without changing the values.
I'm using ElevateDb Mgr v1.04. I thought this would be fixed by now.
I've got some benchmarks to do and I'd like to give as much ram as
possible to the table to see if that speed things up.

Dave

Dave,

<< I see the table buffers still can't be increased in size. I tried to make
the Maximum Row Buffer/Index Buffer Pool Size and as soon as I pressed "Ok"
button, it closes the EdbMgr, without changing the values. I'm using
ElevateDb Mgr v1.04. I thought this would be fixed by now. I've got some
benchmarks to do and I'd like to give as much ram as possible to the table
to see if that speed things up. >>

It's a bug in the EDB Manager's treeview handling for altering tables
interactively - if you simply execute the ALTER TABLE in the EDB Manager it
will work.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Dave,
>
> << I see the table buffers still can't be increased in size. I tried to make
> the Maximum Row Buffer/Index Buffer Pool Size and as soon as I pressed "Ok"
> button, it closes the EdbMgr, without changing the values. I'm using
> ElevateDb Mgr v1.04. I thought this would be fixed by now. I've got some
> benchmarks to do and I'd like to give as much ram as possible to the table
> to see if that speed things up. >>
>
> It's a bug in the EDB Manager's treeview handling for altering tables
> interactively - if you simply execute the ALTER TABLE in the EDB Manager it
> will work.
>
Is there a way I can confirm that it has worked? If I execute the sql
command:

alter table table1 max row buffer size 32000000;

it completes without error, but going back into the EdbMgr and doing an
Alter Table shows the buffers still the same 32k. Is there a way to
generate a "Create Table..." SQL for the existing table so I can confirm
the buffers were changed?

TIA
Dave

Dave,

<< Is there a way I can confirm that it has worked? If I execute the sql
command: >>

Click on the Tables node for the database, and hit the Refresh button.  Any
SQL executed in the SQL window does not immediately take effect in the
treeview/properties without a refresh.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Dave,
>
> << Is there a way I can confirm that it has worked? If I execute the sql
> command: >>
>
> Click on the Tables node for the database, and hit the Refresh button.  Any
> SQL executed in the SQL window does not immediately take effect in the
> treeview/properties without a refresh.
>

Ok, that worked. Thanks.

BTW, if the table is set to read-only at the OS level, the alter table
will still execute but will not report an error. Of course the changes
are not really implemented. I thought it should throw an exception
saying something like "You dumb twit, you've got the file set to
read-only. Get off your lard butt and change it.". Or maybe tone it down
some. I never was any good with customer relations.

Dave

Dave,

<< BTW, if the table is set to read-only at the OS level, the alter table
will still execute but will not report an error. Of course the changes are
not really implemented. I thought it should throw an exception saying
something like "You dumb twit, you've got the file set to read-only. Get off
your lard butt and change it.". Or maybe tone it down some. I never was any
good with customer relations. >>

EDB won't issue such an exception for anything that just alters the memory
buffering settings since they are a catalog-only modification and don't
require any updates to the actual table data.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:869DF4E3-0AAF-4AF6-A264-92F1CA1D7153@news.elevatesoft.com:

> Dave,
>
><< BTW, if the table is set to read-only at the OS level, the alter
>table will still execute but will not report an error. Of course the
>changes are not really implemented... >>
>
> EDB won't issue such an exception for anything that just alters the
> memory buffering settings since they are a catalog-only modification
> and don't require any updates to the actual table data.
>

Just for clarity:

But EDB will give an exception when a program tries to access the modified
parts of the structure of the OS-read-only table whose structure has been
altered in this way, won't it?

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 4 + EDB 1.04 build 3)

Chris,

<< But EDB will give an exception when a program tries to access the
modified parts of the structure of the OS-read-only table whose structure
has been altered in this way, won't it? >>

All metadata for a table is stored in the database catalog.  Whether or not
EDB has to modify the actual tables files depends upon whether the columns
or indexes have changed in a way that warrants it, such as a change to the
data type, etc.  If you don't want any changes to take place to a database,
period, then you should mark both the catalog and the table files as
read-only at the OS level.   That will make the entire database read-only
and no alterations will be permitted (like a read-only media - CD, DVD,
etc.).

--
Tim Young
Elevate Software
www.elevatesoft.com