Tim

Its Friday afternoon and I'm trying to write a test app which is why your getting lots of messages from me today. My normal style is not to fully document the database but create it through a number of iterations. Altering a table is a bit of a nightmare with build 6.

The latest problem is

Go in to alter a table.

1. Try to rename a column from _reference to _Reference. The UI seems to accept it. No problem when I click OK apart from the fact that the alteration isn't made End up dropping the column and re-entering.

2. Want to rename another column from _Source to _Account. Told I can't drop it because it has a linked constraint. OK drop constraint, drop column, re-enter column click OK get error message

ElevateDB Error #300 Cannot lock table Accounts for exclusive access.

This really puzzles me because I'm altering table Transactions!

I had to alter the table, drop the constraint, save the changes, alter the table, drop the column, re-renter the column and save the changes

I appreciate its only a preview but I have one thing to say AAAAAAARRRGGGHHHHH

Roy Lambert

ps

Shame you couldn't just upgrade DBSys since the transition from DBISAM to ElevateDB is going to be so easy <vbg and duck>

Roy,

<< Its Friday afternoon and I'm trying to write a test app which is why your
getting lots of messages from me today. My normal style is not to fully
document the database but create it through a number of iterations. Altering
a table is a bit of a nightmare with build 6. >>

I've only seen on bug report today from you that borders on a major issue,
and I'm not even sure about it (the #700 parsing error).

<< Go in to alter a table.

1. Try to rename a column from _reference to _Reference. The UI seems to
accept it. No problem when I click OK apart from the fact that the
alteration isn't made End up dropping the column and re-entering. >>

Column names are case-insensitive and you can't just change a column name
anyways.  Basically, when the names are the same the EDB manager just
ignores the changes.  You have to drop and then re-add a column in order to
change its name or data type.

<< 2. Want to rename another column from _Source to _Account. Told I can't
drop it because it has a linked constraint. OK drop constraint, drop column,
re-enter column click OK get error message

ElevateDB Error #300 Cannot lock table Accounts for exclusive access.

This really puzzles me because I'm altering table Transactions! >>

Did you have the Accounts table open elsewhere ?  Was the constraint that
you dropped a foreign-key constraint ?  If so, and the target table of the
foreign key was the Accounts table, then EDB will have to open it
exclusively in order to drop the constraint.

<< I appreciate its only a preview but I have one thing to say
AAAAAAARRRGGGHHHHH >>

Well, to be honest a lot of this is just you not being used to the new way
things are done in EDB.  You're comparing apples to oranges and expecting
the two to be the same.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>I've only seen on bug report today from you that borders on a major issue,
>and I'm not even sure about it (the #700 parsing error).

I wasn't talking severity simply the number of problems.

>Did you have the Accounts table open elsewhere ? Was the constraint that
>you dropped a foreign-key constraint ? If so, and the target table of the
>foreign key was the Accounts table, then EDB will have to open it
>exclusively in order to drop the constraint.

I'm not sure it was open, and now you mention RI and I've thought about it a little it makes sense. Also reminds me of other reasons why I can to hate RI

>Well, to be honest a lot of this is just you not being used to the new way
>things are done in EDB. You're comparing apples to oranges and expecting
>the two to be the same.

Very probably, and its a preview so I expect some problems. I'm holding final judgement until 1) the actual release is out and 2) I've used it a bit more. I don't think I'm comparing old to new directly what I'm comparing is the learning curve for the two. DBISAM easy ElevateDB bloody hard (so far).

Roy Lambert

Roy,

<< I wasn't talking severity simply the number of problems. >>

Yeah, but you have to admit that a lot of these problems are simply due to
the fact that you don't quite understand how things work in EDB yet.
Granted, there are certain things that should have been prevented by the EDB
Manager, but those are items that are essentially usability issues with the
manager only.

<< I'm not sure it was open, and now you mention RI and I've thought about
it a little it makes sense. Also reminds me of other reasons why I can to
hate RI >>

Unfortunately EDB has to exclusively lock all tables involved in any RI that
is being modified in the catalog.  Other sessions can't be using outdated
catalog information to enforce RI constraints that are in the process of
being dropped or added.

<< Very probably, and its a preview so I expect some problems. I'm holding
final judgement until 1) the actual release is out and 2) I've used it a bit
more. I don't think I'm comparing old to new directly what I'm comparing is
the learning curve for the two. DBISAM easy ElevateDB bloody hard (so far).
>>

Again, only hard in the sense that you're trying to do things like they were
in DBISAM.  Or, in some cases like RI, you're doing things in EDB that don't
even exist in DBISAM.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>Again, only hard in the sense that you're trying to do things like they were
>in DBISAM. Or, in some cases like RI, you're doing things in EDB that don't
>even exist in DBISAM.

Or how about hard in the sense that I'm not the author

Roy Lambert

Roy,

<< Or how about hard in the sense that I'm not the author >>

Well, I'm sure that I've got rose-tinted glasses at times.  But you do have
to give the new stuff a chance.  I mean, lets be honest - the DBSYS
interface may be very functional in a lot of ways, but it does look like
1998 and doesn't provide even half of the information that EDB does in the
same amount of space.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Well, I'm sure that I've got rose-tinted glasses at times. But you do have
>to give the new stuff a chance. I mean, lets be honest - the DBSYS
>interface may be very functional in a lot of ways, but it does look like
>1998 and doesn't provide even half of the information that EDB does in the
>same amount of space.

It may not seem like it but I am giving it a chance - if I wasn't you wouldn't get any posts from me - I'd have just wiped it from my disk.

DBISAM and Tim have banked a lot of credibility and goodwill over the years and I suspect not only with myself. You could supply a pile of poo and I'd still work very hard to find the good bits.

Roy Lambert

ps I've never been fashion conscious so 1998 is fine by me as long as it does the job <vbg>

Roy,

<< It may not seem like it but I am giving it a chance - if I wasn't you
wouldn't get any posts from me - I'd have just wiped it from my disk. >>

Very true.

<< DBISAM and Tim have banked a lot of credibility and goodwill over the
years and I suspect not only with myself. You could supply a pile of poo and
I'd still work very hard to find the good bits. >>

Thanks.

<< ps I've never been fashion conscious so 1998 is fine by me as long as it
does the job <vbg> >>

Well, if it were simply up to me I'd just tell you all to write your own
database manager.  But, given that we have to provide one, we also need
to make sure that it looks like it was written within the last few years.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

<< Column names are case-insensitive and you can't just change a column name
anyways.  Basically, when the names are the same the EDB manager just
ignores the changes.  You have to drop and then re-add a column in order to
change its name or data type. >>

1) So how do you rename a column and still keep its data? I made a typing mistake in the
name and had to drop the existing column and add a new column. How do I preserve the data
doing it this way?

2) Also, can I assume the EDB Mgr will eventually have filtering and ranges added?

3a) How do I create a live query? Everything I execute is static and I'm dealing with
large tables and it takes 4 minutes to get the results back.
3b) Is there a "LIMIT n" or "Top n" syntax for the Select statement? I looked in the help
file and couldn't find any mention of it.

TIA

Sam

Sam,

<< 1) So how do you rename a column and still keep its data? I made a typing
mistake in the name and had to drop the existing column and add a new
column. How do I preserve the data doing it this way? >>

Dropping and adding a column with the same name will preserve its data.
However, if you need to rename a column then there is no way currently for
EDB to know how to match up the data, so the column data is not transferred.

<< 2) Also, can I assume the EDB Mgr will eventually have filtering and
ranges added? >>

It already has filters, but no, it won't have ranges.

<< 3a) How do I create a live query? >>

In the EDB Manager ?  If so, then make sure to check the Request Sensitive
check box.  In EDB, "live" query result sets are now referred to as
"sensitive" query result sets ?

<< 3b) Is there a "LIMIT n" or "Top n" syntax for the Select statement? I
looked in the help file and couldn't find any mention of it. >>

No.  We'll be implementing something like this later, but it will use the
standard windowing syntax in SQL 2003.

--
Tim Young
Elevate Software
www.elevatesoft.com