Tim,
>
> I've used your reverse engineer option to create the Delphi code to create
> the tables programatically.
>
> If I remember right, I thought you stated that the best/only way in
> ElevateDB will be to now create / delete tables via SQL only.
>

In DBSYS utility there is amongst others reverse engineering possibility to
make a Pascal code. I used it very extensively not only in a way just to
create new table but also for detection of lower verions of table and
automatic upgrading of a table using my upgrading code.

Is there a substantial reason for omitting this possibility in ElevateDB and
further, can you preserve this possibility in ElevateDB?

Regards
Iztok Lajovic

Stefano

At least a feature "using INDEX <index_name>" will be very useful in query
processing.

Sample:

select * from table1
where field1=100 and field2='Test' and field3='2006-12-04'
using index index2

Eduardo

Iztok,

<< Is there a substantial reason for omitting this possibility in ElevateDB
and further, can you preserve this possibility in ElevateDB? >>

You don't need it in ElevateDB.  You can create a single stored procedure
that creates all of the necessary catalog objects for a given database,
complete with version checking, etc.

In addition, having dual Delphi/SQL methods of doing the same thing, such as
with DBISAM, was a documentation and testing nightmare.

--
Tim Young
Elevate Software
www.elevatesoft.com

Eduardo,

<< AFAIK, ElevateDB will have stored procedures but queries and compound
queries is the most improvement I want. I have some large tables (more than
1 million records) and I have to use auxiliar fields simulating compound
indexes, this works but it is not the best way to find records. >>

Why on earth would you have to use additional fields to simulate compound
indexes ?  Either you need compound indexes for sorting or key (primary or
unique) purposes or you don't, and if you don't, then just create indexes on
the individual columns as necessary and DBISAM can use them all for
optimizing a compound expression in a WHERE or JOIN clause.

--
Tim Young
Elevate Software
www.elevatesoft.com

<< Why on earth would you have to use additional fields to simulate compound
indexes ?  Either you need compound indexes for sorting or key (primary or
unique) purposes or you don't, and if you don't, then just create indexes on
the individual columns as necessary and DBISAM can use them all for
optimizing a compound expression in a WHERE or JOIN clause. >>

Well, I have some situation with 4 or more fields to be compared.
Example:

where emp=1 and ser='2' and des=1234 and cf1='05' and cf2='02'

and it takes some time but when I concatenate this fields into an auxiliar field the expression
become

where aux='1;2;1000;1234;05;02'

and it is faster than (a lot) than the first situation. All of the fields is indexed (first field of index). That is the
reason. I think ElevateDB can use compound index for some circunstances because I have a key with emp,ser
and des fields. The situation occurs (I think) because that are a lot of records with emp=1 and almost 80% with
ser='2'.

Eduardo

Hi Tim,
I think to works still 10 years within software (after I go to play music
);
Can you assure me that I will able to use Elevatedb in the meantime ?

Stefano


> You don't need it in ElevateDB.  You can create a single stored procedure
> that creates all of the necessary catalog objects for a given database,
> complete with version checking, etc.
>

Stefano,

<< I think to works still 10 years within software (after I go to play music
);
Can you assure me that I will able to use Elevatedb in the meantime ?
>>

Yes, it should be more than usable for you.

--
Tim Young
Elevate Software
www.elevatesoft.com

Eduardo,

<< Well, I have some situation with 4 or more fields to be compared.
Example:

where emp=1 and ser='2' and des=1234 and cf1='05' and cf2='02'

and it takes some time but when I concatenate this fields into an auxiliar
field the expression become

where aux='1;2;1000;1234;05;02'

and it is faster than (a lot) than the first situation. >>

Sure, but the reason is that most likely you don't have any index on the
more selective columns in the compound expression.  Do you have indexes on
all of the columns, or just some ?  And if some, then which columns ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>
> where emp=1 and ser='2' and des=1234 and cf1='05' and cf2='02'
>
> Sure, but the reason is that most likely you don't have any index on the
> more selective columns in the compound expression.  Do you have indexes on
> all of the columns, or just some ?  And if some, then which columns ?

There are indexes for ALL columns in the expression
emp
ser
des
cf1
cf2

Eduardo

Eduardo,

<< There are indexes for ALL columns in the expression >>

Could you send me an empty table structure or a list of the fields and
indexes for that table ?  If all columns are indexed, then the query should
be quick unless compression is not enabled for the indexes or there is an
issue with an index with a larger index key being used.

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com