Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 7 of 7 total |
Internal versioning |
Mon, Sep 28 2009 11:28 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Mon, Sep 28 2009 12:23 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Mon, Sep 28 2009 1:03 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Mon, Sep 28 2009 1:50 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Sep 29 2009 3:48 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Tue, Sep 29 2009 4:31 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Wed, Sep 30 2009 3:43 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |