Board index » delphi » Paradox auto-increment and tbatchmove BUGS

Paradox auto-increment and tbatchmove BUGS

I intended sending this to a borland email address, of which none are available
for technical queries, so I am posting this in the newsgroups with the hope
that someone has had a similar problem, or that someone from borland reads
this:

I am using Borland Delphi v1.0 with the paradox v5.0 file driver. I have
recently hit upon a major problem/bug which has completely halted development
of a program that I have been working on.

The problem seems to revolve around the auto-increment fields in the paradox
file system. Very simply, all I want to do is to change my end-users
data-structures without changing the values in any of the fields. I can do this
quite easily using TBatchMove, but the values in every auto-increment field are
changed. This is completely unacceptable, and unusable. There is now no way
that I can change my end-users data structures without going to each and every
field and each and every table that has changed, and use the database desktop
to restructure.

My only option seems to be to remove all auto-increment fields, and generate
these manually. Surely most Paradox users have hit this problem, and surely by
now there is a simple solution ? I have an auto-increment field in every single
one of my tables, and I must now remove every one of these and replace with
hand-written code.

I have tried a number of suggested solutions with absolutely no luck
whatsoever:

I have tried changing all fields from auto-increment to long integers before
doing the TBatchMove, but because I am using referential integrity this is not
allowed.

I have tried upgrading to the latest release of the 16bit BDE, but after
installing and using TBatchMove, it still renumbers everything.

I have tried the batcopy mode, which seems to maintain the auto-increment
fields but trashes all index definitions.

I have been told about DbiDoRestructure which I think is called by the database
desktop when restructuring tables, but to my knowledge, there is no simple way
of using this.

I am ready to remove all auto-increment fields and start again. I think Borland
should either remove features that dont work, or say very loudly and very
clearly what known problems exist with them. An immense amount of time can be
wasted when one assumes that something that is supposed to work does not.

I would very much appreciate any sort of help - thanks, Simon Welsh...

 

Re:Paradox auto-increment and tbatchmove BUGS


Quote
we...@uctvms.uct.ac.za wrote:

> I intended sending this to a borland email address, of which none are available
> for technical queries, so I am posting this in the newsgroups with the hope
> that someone has had a similar problem, or that someone from borland reads
> this:

> I am using Borland Delphi v1.0 with the paradox v5.0 file driver. I have
> recently hit upon a major problem/bug which has completely halted development
> of a program that I have been working on.

> The problem seems to revolve around the auto-increment fields in the paradox
> file system. Very simply, all I want to do is to change my end-users
> data-structures without changing the values in any of the fields. I can do this
> quite easily using TBatchMove, but the values in every auto-increment field are
> changed. This is completely unacceptable, and unusable. There is now no way
> that I can change my end-users data structures without going to each and every
> field and each and every table that has changed, and use the database desktop
> to restructure.

> My only option seems to be to remove all auto-increment fields, and generate
> these manually. Surely most Paradox users have hit this problem, and surely by
> now there is a simple solution ? I have an auto-increment field in every single
> one of my tables, and I must now remove every one of these and replace with
> hand-written code.

> I have tried a number of suggested solutions with absolutely no luck
> whatsoever:

> I have tried changing all fields from auto-increment to long integers before
> doing the TBatchMove, but because I am using referential integrity this is not
> allowed.

> I have tried upgrading to the latest release of the 16bit BDE, but after
> installing and using TBatchMove, it still renumbers everything.

> I have tried the batcopy mode, which seems to maintain the auto-increment
> fields but trashes all index definitions.

> I have been told about DbiDoRestructure which I think is called by the database
> desktop when restructuring tables, but to my knowledge, there is no simple way
> of using this.

> I am ready to remove all auto-increment fields and start again. I think Borland
> should either remove features that dont work, or say very loudly and very
> clearly what known problems exist with them. An immense amount of time can be
> wasted when one assumes that something that is supposed to work does not.

> I would very much appreciate any sort of help - thanks, Simon Welsh...

Hello !
 I understand your frustrations and problem with autoincrement-fields,
I have also wasted hours on this subject ... In general, stay away from
this type of field. All experience says that sooner or later you will
run into problems with autoincrement. When ID-fields are required, do
all increments and maintenance in your application code. Of course, this
is a little more clumbersome than just to pick a predefined field-type
from a list.

Regards
Atle Markeng
DataMar, Oslo-Norway

Re:Paradox auto-increment and tbatchmove BUGS


Quote
datamar wrote:

> we...@uctvms.uct.ac.za wrote:

> > I intended sending this to a borland email address, of which none are available
> > for technical queries, so I am posting this in the newsgroups with the hope
> > that someone has had a similar problem, or that someone from borland reads
> > this:

> > I am using Borland Delphi v1.0 with the paradox v5.0 file driver. I have
> > recently hit upon a major problem/bug which has completely halted development
> > of a program that I have been working on.

> > The problem seems to revolve around the auto-increment fields in the paradox
> > file system. Very simply, all I want to do is to change my end-users
> > data-structures without changing the values in any of the fields. I can do this
> > quite easily using TBatchMove, but the values in every auto-increment field are
> > changed. This is completely unacceptable, and unusable. There is now no way
> > that I can change my end-users data structures without going to each and every
> > field and each and every table that has changed, and use the database desktop
> > to restructure.

> > My only option seems to be to remove all auto-increment fields, and generate
> > these manually. Surely most Paradox users have hit this problem, and surely by
> > now there is a simple solution ? I have an auto-increment field in every single
> > one of my tables, and I must now remove every one of these and replace with
> > hand-written code.

> > I have tried a number of suggested solutions with absolutely no luck
> > whatsoever:

> > I have tried changing all fields from auto-increment to long integers before
> > doing the TBatchMove, but because I am using referential integrity this is not
> > allowed.

> > I have tried upgrading to the latest release of the 16bit BDE, but after
> > installing and using TBatchMove, it still renumbers everything.

> > I have tried the batcopy mode, which seems to maintain the auto-increment
> > fields but trashes all index definitions.

> > I have been told about DbiDoRestructure which I think is called by the database
> > desktop when restructuring tables, but to my knowledge, there is no simple way
> > of using this.

> > I am ready to remove all auto-increment fields and start again. I think Borland
> > should either remove features that dont work, or say very loudly and very
> > clearly what known problems exist with them. An immense amount of time can be
> > wasted when one assumes that something that is supposed to work does not.

> > I would very much appreciate any sort of help - thanks, Simon Welsh...

> Hello !
>  I understand your frustrations and problem with autoincrement-fields,
> I have also wasted hours on this subject ... In general, stay away from
> this type of field. All experience says that sooner or later you will
> run into problems with autoincrement. When ID-fields are required, do
> all increments and maintenance in your application code. Of course, this
> is a little more clumbersome than just to pick a predefined field-type
> from a list.

> Regards
> Atle Markeng
> DataMar, Oslo-Norway

I totally agree with Atle - this field type seems to be very handy at
first glance and can be a nightmare when you use it. So: don't use it -
no other BDE file type supports it anyway.
Gyula Karakas
Vmszoft-Budapest, Hungary

Re:Paradox auto-increment and tbatchmove BUGS


Quote
we...@uctvms.uct.ac.za wrote:
> I am ready to remove all auto-increment fields and start again. I think Borland
> should either remove features that dont work, or say very loudly and very
> clearly what known problems exist with them. An immense amount of time can be
> wasted when one assumes that something that is supposed to work does not.

> I would very much appreciate any sort of help - thanks, Simon Welsh...

Your bluster and handwringing angst bely your obvious inexperience. An
autoincrement field is specifically designed, your description of your
problem doesn't describe a single bug or even a badly designed peice
of functionality on Borland's behalf.

Duncan.
dmarg...@scomhbr3.telstra.com.au

Re:Paradox auto-increment and tbatchmove BUGS


In article <32062ACD.4...@scomhbr3.telecom.com.au>, Duncan Margetts <dmarg...@scomhbr3.telecom.com.au> writes:

Quote
> we...@uctvms.uct.ac.za wrote:

>> I am ready to remove all auto-increment fields and start again. I think Borland
>> should either remove features that dont work, or say very loudly and very
>> clearly what known problems exist with them. An immense amount of time can be
>> wasted when one assumes that something that is supposed to work does not.

>> I would very much appreciate any sort of help - thanks, Simon Welsh...

> Your bluster and handwringing angst bely your obvious inexperience. An
> autoincrement field is specifically designed, your description of your
> problem doesn't describe a single bug or even a badly designed peice
> of functionality on Borland's behalf.

> Duncan.
> dmarg...@scomhbr3.telstra.com.au

In isolation, the auto-increment feature does work, in that it automatically
increments the values in a field as new records are added to the table. In this
respect it contains no bugs as far as I know. However, a feature such as this
is completely useless if used in isolation. Obviously any normal user is going
to want to restructure tables at some or other time, add a new field perhaps,
maybe a new secondary index. With an auto-increment field you can do this, but
as designed, your fields will all be re-incremented. This is fine if all you
require are unique numbers on your records that change from time to time.

If, however, like most programmers, you link to other tables using an
auto-incrementing field, all links to other tables will suddenly become
invalid. This is a total disaster, making the Borland Paradox v5.0
implementation of this feature COMPLETELY USELESS.

- Simon..

Other Threads