Tim

Are you near figuring out a usable solution for this

ElevateDB Error #100 There is an error in the metadata for the table EMails (The internal version does not match the version in the configuration or catalog)

I have tables which are identical in structure and I need to pull the live data back for just one table (c 1Gb) but I can't because of this restriction. I know there's a good reason for it now the metadata isn't in with the data and that there are workrounds but it would make my life a LOT easier if I could just copy the data back.


Roy Lambert

Roy,

<< Are you near figuring out a usable solution for this

ElevateDB Error #100 There is an error in the metadata for the table EMails
(The internal version does not match the version in the configuration or
catalog)

I have tables which are identical in structure and I need to pull the live
data back for just one table (c 1Gb) but I can't because of this
restriction. I know there's a good reason for it now the metadata isn't in
with the data and that there are workrounds but it would make my life a LOT
easier if I could just copy the data back. >>

You're over-simplifying the situation.  If the internal version number
changed, it's because something changed with respect to the structure of the
table.  Therefore, you can't just "copy the data back" because the current
catalog would have no idea how to properly read the table (the structure
changed).

Remember, there are things like RI now that need to be taken into account,
so EDB must treat a database as a whole, and not as a collection of
individual tables.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>You're over-simplifying the situation.

Sorry Tim, I'm not.

>If the internal version number
>changed, it's because something changed with respect to the structure of the
>table. Therefore, you can't just "copy the data back" because the current
>catalog would have no idea how to properly read the table (the structure
>changed).

I'm not sure if that's over complicating, over simplifying or just healthy paranoia. Consider an example:

create a table with two fields A INTEGER and B INTEGER

the app goes live, as part of ongoing development I think B would be better as a VARCHAR so I change the table. I then decide I was wrong and change it back to INTEGER.

The version numbers between the live and development tables are now different, but the tables have the same structure. I don't think that's over-simplifying. Its real life and happens quite a bit (at least to me).

Tools to handle this easily would be very useful as part of the development cycle.

Roy Lambert

Roy,

<< I'm not sure if that's over complicating, over simplifying or just
healthy paranoia. Consider an example:

create a table with two fields A INTEGER and B INTEGER

the app goes live, as part of ongoing development I think B would be better
as a VARCHAR so I change the table. I then decide I was wrong and change it
back to INTEGER.

The version numbers between the live and development tables are now
different, but the tables have the same structure. I don't think that's
over-simplifying. >>

There is quite a bit more in a table that can change, and you've picked the
simplest example one can think of.

<< Tools to handle this easily would be very useful as part of the
development cycle. >>

There are tools to handle this - you can use importing and exporting to do
so, or use INSERT INTO..SELECT to get the data from the old database to the
new database.

You're essentially asking to mix a newer catalog with an older set of table
files, and that's a recipe for disaster in the hands of someone that doesn't
remember that they also changed some other items (like indexes) in the
catalog also.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>There is quite a bit more in a table that can change, and you've picked the
>simplest example one can think of.

I know there are many more things that can change and I used a simple example because it was a) a lot less typing and b) there are probably a lot of simple tables out there

I could have given the full spec for both tables involved which would have made the same point but taken up a lot more space

><< Tools to handle this easily would be very useful as part of the
>development cycle. >>
>
>There are tools to handle this - you can use importing and exporting to do
>so, or use INSERT INTO..SELECT to get the data from the old database to the
>new database.

We've been through this circle before. There are generally ways to do things but the point is not that I can do it in another fashion but that it takes 10 times as long to do it, and is more awkward.

>You're essentially asking to mix a newer catalog with an older set of table
>files, and that's a recipe for disaster in the hands of someone that doesn't
>remember that they also changed some other items (like indexes) in the
>catalog also.

I accept that, but spreadsheets are a recipe for disaster the world over and we've survived them. Developers are meant to know what they're doing, and if I had a mismatch such as you propose I think it would be good to have it brought to my attention

Roy Lambert

Roy,

<< I know there are many more things that can change and I used a simple
example because it was a) a lot less typing and b) there are probably a lot
of simple tables out there >>

Sure, but it doesn't reflect the reality of trying to determine the exact
state of the table files in relation to the catalog metadata, which is much
more than a simple column difference.  There are identity columns, indexes,
constraints, etc. that all need to be taken into account.

I'll see if there's a solution here with checksums (CRC32, most likely,
since we don't have space for an MD5 hash), but it's not something that can
be done quickly.  If it's not done correctly, then we'll be in a mess o'
trouble.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Sure, but it doesn't reflect the reality of trying to determine the exact
>state of the table files in relation to the catalog metadata, which is much
>more than a simple column difference. There are identity columns, indexes,
>constraints, etc. that all need to be taken into account.

Yes but you're so good at that

>I'll see if there's a solution here with checksums (CRC32, most likely,
>since we don't have space for an MD5 hash), but it's not something that can
>be done quickly. If it's not done correctly, then we'll be in a mess o'
>trouble.

I agree that it needs to be done correctly, and my main reason for it is during the development stage, but it would also be useful when live. I'll keep on pestering at intervals


Roy Lambert