I want to modify column properties with EDBMgr.
To do this, I click on Alter Table, display the columns, select the right column and
modify f.ex. the length of a varchar field from 20 to 30. But if I click on Alter column,
it says: Only the description and/or Default expression may be modified for the existing
column Fax. The same also with renaming the field, or changing some other attributes like
Case insensitive.
I played a bit around and then I found that suddenly it worked with a column!!?
I investigated this and it seems that this depends on whether the column had been migrated
from DBIsam or whether it had been added as a new column in EDBMgr. It looks like that the
migrated columns can't be altered while those created within EDBMgr can.

BUT: when I then click on OK to close the Alter table dialog, it tells me: ElevateDB Error
#700: An error was found in the statement at line 6 and column 0 (missing ADD, ALTER, DROP)

So, what is wrong here? I can't believe that I am too stupid to manage such simple things
like changing a data table structure...


Best regards
Stephan Krämer

Stephan,

<< I investigated this and it seems that this depends on whether the column
had been migrated
from DBIsam or whether it had been added as a new column in EDBMgr. It looks
like that the migrated columns can't be altered while those created within
EDBMgr can.  >>

This is correct.   If you want to modify a column property other than the
default or the description, you have to drop the column, re-add it, and then
move it to the desired position.

<< BUT: when I then click on OK to close the Alter table dialog, it tells
me: ElevateDB Error
#700: An error was found in the statement at line 6 and column 0 (missing
ADD, ALTER, DROP) >>

If you look at the SQL tab for the database being used, you will see the SQL
that is being generated by the ALTER TABLE dialog.  If you could post it
here along with the steps that you took while using the alter table dialog,
I can tell you what is going wrong and how to correct it.  Most likely the
alter table dialog is generating invalid SQL for some reason.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

>>>
This is correct.   If you want to modify a column property other than the
default or the description, you have to drop the column, re-add it, and then
move it to the desired position.
<<<

So you are saying, I should write down all field properties on paper, remove that column
and then recreate it? You are going back to stone-age with EDB...
Today I can expect from a database system that it provides a tool by which I can do any
structure definitions on screen in a comfortable way. But EDBMgr is not only a hard to use
software, it also lacks of such simple basic tasks like renaming columns or modifying text
field lengths. These are everyday tasks for a database programmer. Others have stated here
in this group that you seem to have forgotten the developers (especially because EDBMgr is
an uncomfortable tool), and this is one more proof.
Your company has DBIsam which provides such features (although DBSys is not what I
consider as an easy-to-use software) and now with EDBMgr you are going some more steps back.
A new UI does not compensate missing basic features. Your admittedly fast service and fast
bug fixing does not compensate missing basic features and it does not compensate some
wrong design details.

I am sorry, this seems to be my end as an EDB developer. As a long-time Delphi developer
(since TurboPascal 1.0) and long-time DBIsam developer, I was hoping to be able to
continue the rest of my business life with D2007 and EDB and their successors, but now it
is clear that this is the wrong way.
I will have to switch to other databases, .Net, C# and Visual Studio which provide all
those up-to-date tools (especially for DB handling) for a programmer.

Don't take this personally like with earlier posts. This is just my personal conclusion of
everything which I had to experience with EDB during the past months. I hope you can also
take some conclusions from that and I wish you and your company good success for the future.

Best regards
Stephan Krämer

Stephan

>So you are saying, I should write down all field properties on paper, remove that column
>and then recreate it? You are going back to stone-age with EDB...

No - In EDBMan click on the column you want to delete, EDBMan populates the various editboxes with the definition  data for the column. Click delete. Alter the bits you want to alter, click add and move it where you want.

>Today I can expect from a database system that it provides a tool by which I can do any
>structure definitions on screen in a comfortable way. But EDBMgr is not only a hard to use
>software, it also lacks of such simple basic tasks like renaming columns or modifying text
>field lengths. These are everyday tasks for a database programmer. Others have stated here
>in this group that you seem to have forgotten the developers (especially because EDBMgr is
>an uncomfortable tool), and this is one more proof.

These are achievable. Not exactly in the way I would like but certainly usable. The switch from DBSys to EDBMan (and DBISAM to ElevateDB) is a bit traumatic but will I consider be worthwhile in the long term.

>Your company has DBIsam which provides such features (although DBSys is not what I
>consider as an easy-to-use software)

What do you consider as easy-to-use database management software?

>and now with EDBMgr you are going some more steps back.
>A new UI does not compensate missing basic features. Your admittedly fast service and fast
>bug fixing does not compensate missing basic features and it does not compensate some
>wrong design details.

I don't think it lacks basic features, just that they're not presented in the best way possible. If you notice some of my posts I do keep going on about the bits I want changed. My view is that Tim will listen (admittedly sometime you have to shout) and will respond. His workload is currently more focused on the engine than the management tools and I for one think that is the right way. I'd much prefer a rock solid and fast engine to a pretty interface with a lousy backend.

>
>I am sorry, this seems to be my end as an EDB developer. As a long-time Delphi developer
>(since TurboPascal 1.0) and long-time DBIsam developer, I was hoping to be able to
>continue the rest of my business life with D2007 and EDB and their successors, but now it
>is clear that this is the wrong way.
>I will have to switch to other databases, .Net, C# and Visual Studio which provide all
>those up-to-date tools (especially for DB handling) for a programmer.

Bye then

Roy Lambert

Stephan,

It took me a while to getting used with EDBmngr, but all of the 'basic'
stuff is there. Also I think that in August (Tim, correct me if I'm wrong)
huge improvements to EDBmngr are ready. Pitty that you decide to leave EDB.
EDB is really a great database, and getting better still. I hope you're not
gonna regret leaving it, but I think you will.

Regards, Harry

"Stephan Krämer" <stkraemer@sportsoftware.de> schreef in bericht
news:639288B7-2DC5-48CD-8676-A938649FF525@news.elevatesoft.com...
> Tim,
>
> >>>
> This is correct.   If you want to modify a column property other than the
> default or the description, you have to drop the column, re-add it, and
then
> move it to the desired position.
> <<<
>
> So you are saying, I should write down all field properties on paper,
remove that column
> and then recreate it? You are going back to stone-age with EDB...
> Today I can expect from a database system that it provides a tool by which
I can do any
> structure definitions on screen in a comfortable way. But EDBMgr is not
only a hard to use
> software, it also lacks of such simple basic tasks like renaming columns
or modifying text
> field lengths. These are everyday tasks for a database programmer. Others
have stated here
> in this group that you seem to have forgotten the developers (especially
because EDBMgr is
> an uncomfortable tool), and this is one more proof.
> Your company has DBIsam which provides such features (although DBSys is
not what I
> consider as an easy-to-use software) and now with EDBMgr you are going
some more steps back.
> A new UI does not compensate missing basic features. Your admittedly fast
service and fast
> bug fixing does not compensate missing basic features and it does not
compensate some
> wrong design details.
>
> I am sorry, this seems to be my end as an EDB developer. As a long-time
Delphi developer
> (since TurboPascal 1.0) and long-time DBIsam developer, I was hoping to be
able to
> continue the rest of my business life with D2007 and EDB and their
successors, but now it
> is clear that this is the wrong way.
> I will have to switch to other databases, .Net, C# and Visual Studio which
provide all
> those up-to-date tools (especially for DB handling) for a programmer.
>
> Don't take this personally like with earlier posts. This is just my
personal conclusion of
> everything which I had to experience with EDB during the past months. I
hope you can also
> take some conclusions from that and I wish you and your company good
success for the future.
>
> Best regards
> Stephan Krämer
>

Stephan,

>
> I am sorry, this seems to be my end as an EDB developer. As a long-time Delphi developer
> (since TurboPascal 1.0) and long-time DBIsam developer, I was hoping to be able to
> continue the rest of my business life with D2007 and EDB and their successors, but now it
> is clear that this is the wrong way.

Being a developer for such a long time you have to admit that nothing
you have experienced in the past was perfect at the beginning. This
stands for whatever we develop. And beside bugs "perfect" very much
depends on the user taste.


> I will have to switch to other databases, .Net, C# and Visual Studio which provide all
> those up-to-date tools (especially for DB handling) for a programmer.
>

Don't believe you will be better of in doing so. You will find and
experience with these lots of other issues you don't like.

> Don't take this personally like with earlier posts. This is just my personal conclusion of
> everything which I had to experience with EDB during the past months. I hope you can also
> take some conclusions from that and I wish you and your company good success for the future.
>

Well your post is a personal offence! From the experience I have made
with component and database vendors Tim (and his prodcuts!) is the least
who deserves such a post.

Arnd

Hi Arnd,

>>
Don't believe you will be better of in doing so. You will find and
experience with these lots of other issues you don't like.
<<
If you consider the Delphi world only, then you are right. I wanted to  stay with Delphi,
and for that there is no alternative to EDB. I discussed this with Tim.
However, there are better alternatives, once you make up your mind and switch to .Net.



> Don't take this personally like with earlier posts. This is just my personal conclusion of
> everything which I had to experience with EDB during the past months. I hope you can also
> take some conclusions from that and I wish you and your company good success for the future.
>
>>
Well your post is a personal offence! From the experience I have made
with component and database vendors Tim (and his prodcuts!) is the least
who deserves such a post.
<<

Why do you not believe my statement? Take this in that way as I had written above, period.

Best regards
Stephan Krämer

Hi Roy,

>>

What do you consider as easy-to-use database management software?
<<

Look at Visual Studio and how you can manipulate everything with databases directly within
the IDE. You can also define relationships there with ease. This is a feature which is
completely missing in EDB. This does not only work with their SQL Server express but also
with 3rd party products.

I think I remember that you had proposed some good ideas for EDBMgr, so I think you do
also have strong ideas what is missing in EDBMgr so far.


Best regards
Stephan Krämer

Stephan,

<< ... what is missing in EDBMgr so far ... >>

"so far"

I think that's where we differ. Many of us believe strongly that Tim is one of
the best "listeners" around, when it comes to implementing features which his
customers are asking for.

The truth is, no software developer can deliver *all the features at once*. Roy did
point out that Tim is concentrating on making the database engine rock solid, and I also
applaud that decision. In the meanwhile, some of us can live with a visual DB manager
which is admittedly less than ideal "so far".

Regards,
Dan

Stephan

>Look at Visual Studio and how you can manipulate everything with databases directly within
>the IDE. You can also define relationships there with ease. This is a feature which is
>completely missing in EDB. This does not only work with their SQL Server express but also
>with 3rd party products.

Interesting comparison. If Visual Studio does what you want then I would suggest using it. If, however, you want something changing, or a bug fixing you could have a long wait.

>I think I remember that you had proposed some good ideas for EDBMgr, so I think you do
>also have strong ideas what is missing in EDBMgr so far.

I have some ideas as to what I would like to see. I also recognise that not everyone will want the same thing, and as I said in one post, if there's stuff that I want that Tim won't add in I'll do it myself.

You could also look at things like the Context stuff http://www.contextsoft.com/products/dbdesign/screencasts.jsp

Roy Lambert