Hi Raul,

While data integrity is good, my opinion would be that all of the functionality of a table should be transferred by a migration utility.  If something is in a BDE table, it should be transferred to the DBISAM table.

I'll contact Tim next week if he doesn't see this and see what he says.

Raul wrote:

It's an interesting question since you have no data in the table - just
my opinion but main goal of the db conversions is to retain data
integrity and that did take place here (i.e. your other data has the
right values).

Rick Hillier wrote:

> I don't know why it is considered problematic to use something that
> is built into the database to get the "next" value for a job number
> (as I had mentioned, there are reasons for doing things this way in
> my application that would take a long time to explain).

For what it is worth, my understanding is that it is "problematic" to
use the auto-inc value because when things go wrong, or you need to
migrate to another system, the data integrity and operation of it can
give you grief. It isn't insoluble, and it isn't big, but if you have
your own number incrementing system, it can remove some of that strain
(though not all of course).

A small example of how it can help - our office uses this
self-numbering to allocate customer reference numbers. But we'd
pre-allocated the range 2000 to 3999 for a big batch sold via a
reseller (we were quite new at the time!). So the auto-numbering system
had code so that when it got to 1999 the increment went to 4000. Can't
do that using the database system's auto-inc.

That said, I use the auto-inc all the time for many things, so it's not
like I'm against it. If I don't really need control, then it's not a
problem. And I migrated from DBISAM to ElevateDB easily. (Which raises
another question really - why are you going to DBISAM and not
ElevateDB).

Anyway, good luck with the migration, I suspect you can change the next
value manually if required.

--

Matthew Jones

Matthew


I'd pretty much agree with you, but my way of expressing it would be - autoincs should be used for internal numbering & consistency but not for external reference. You quoted customer number, mine would be invoice numbering - my invoices get numbered MMDD/nnn (sequence in the month) - can't do that with an autoinc

Roy Lambert

Roy Lambert wrote:

> my way of expressing it would be - autoincs should be used for
> internal numbering & consistency but not for external reference.

Well put. And of course generally not ever a problem, until it is. 8-)
That's when the db admin earns their crust.

--

Matthew Jones