Data loss when publishing BSV

aware_support

Like I said, if you develop on the same machine Aware IM has access to the BSV version that is current in the database. It does the comparison automatically and warns you if something is wrong even before you publish. This is why it's beneficial. If you develop on a different machine the best thing to do is to publish the same version of the BSV that you have on the production machine before you make any changes (even if there is no data).

RocketRod

Thanks as well support. A suggestion would be to have a function similar to the integrity check which is a file check. Developers could then run this to see what AwareIm will do to the database if the bsv is published.

Cheers Rod

kklosson

I strongly support this suggestion.

hpl123

Rennur

This is very concise explanation on how the system interacts with the database.
It certainly cleared up why I've been having some database structure issues.

Thank you

chris29

I agree with Rod, to have an idea of what's about to happen would be ideal, and save a lot of grief when deploying.

One question is when AwareIM finds duplicate Attribute ID's and its corrected (Ctrl-I) if these ID's no longer match a deployed bsv and I right in thinking the data is removed when deploying to another server?

kklosson

So what about a runtime deployment? If I get a duplicate ID error during configuration, should I be worried that this will impact data on the target machine?

I've got to say, I am very, very concerned with all of this.

If data loss may be caused by a duplicate ID, then there should be no such thing.

chris29

Yes, I have had the duplicate Attribute ID's issue many times.

Sometimes it's just one or two attributes but the other week it was a hundred or more as it scrolled off the config tool console window.

It's a worry as I have no idea what data may now disappear. 😮

kklosson

Absolutely unacceptable.

Rennur

One example: you delete an attribute and save the object. An attribute with this id is now gone. You create an attribute again WITH THE SAME NAME. However, it has a DIFFERENT internal id now. You think that it's the same attribute, though, and don't expect Aware IM to make any changes. But it does and you have problems.

I've had this happen a number of times & I've posted here about the problem. Every time I had to restore from backup. on one occasion, I had to export individual tables into .csv, restore BSV and re import each .csv one by one to get the new BSV structure right.
Almost every time I had do a CTRL-I duplicate ID check.

Now I understand why and how this is happening. This explanation, if on already, should be in the User Guide as a caution.

Before deleting a BO or even an deleting an attribute, the database and the BSV should be backed up.

kklosson

When I first started using AwareIM, I felt there was a pact between the developer and AwareIM that the developer needs to tend to business objects and AwareIM will manage the database. This is a grand bargain in my view.

I completely understand what Support has stated regarding consistency in databases, but my experience has been that data deletion may occur when the developer has done nothing in configuration to cause it and it may occur with no warning or any other indicator to alert the configurator that it will happen.

There are several suggestions in this thread that could alleviate this issue to one degree or another. I encourage AwareSoft to consider them.

Rennur

There are several suggestions in this thread that could alleviate this issue to one degree or another. I encourage AwareSoft to consider them.

I agree 100%

RocketRod

Further to my suggestion I've had some more thoughts. I think that the file check should be available outside of the configuration tool. It can then prompt for a bsv file, which the developer can of course export. It should also prompt for the database name. In this way developers can check a bsv against a DB on a different machine AND it would assist developers who distribute runtime versions. Runtime version upgrades can be especially thwarft with danger if you have upgraded your AwareIM version several times and made quite a few changes to the BSV. In these instances the developer has no idea if they will encounter issues when distributing their new runtime or not.

Cheers Rod

kklosson

Another excellent contribution. I must say, I'm alarmed that several have come out with similar experiences, especially in the runtime environment.

A note to AwareSoft: AwareIM is a sound product and we in this thread are huge devotees. I believe this thread demonstrates a vulnerability which, despite the soundness of the product and the care taken by the developer, can leave one with a damaged database and no indication that the database was affected in an unforeseen manner. The observations and suggestions here are offered in hopes that you can provide developers with a bit more visibility into the database actions to be taken when a BSV is published or put into testing mode. We heard you say that the database update aspect of publishing a BSV is complex. No doubt it is. But we respectfully ask that you give this thread some consideration and contemplate what can be done to improve this aspect of AwareIM.

aware_support

Thank you for your suggestions, we'll consider them

hpl123

Support / all,
I have a question related to these problems. If I have a live BSV (v1), do some changes to the BS and publish a new BSV (v2). The structure of the database (v2) would now be different because I have changed the application. If I then restore a database backup (using NaviCat) from before the BS changes (i.e. restore database from v1 to database of v2), wouldn´t that mean the new changes I have made to the BSV (v2) would be lost because the restore of a backup restores structure and data from v1?.

I am a DB etc. newbie so any help, comments etc. are appreciated and this is a VERY IMPORTANT thing. Please enlighten me 🙂. Thanks

PS: Thanks support for considering creating better tools to counteract the problems discussed in this post.

aware_support

Yes, database restore will restore the system to v1 and the changes to v2 will be lost unless you also save v2 as a BSV file before you restore and import it again, then publish again.

hpl123

aware_support wrote
Yes, database restore will restore the system to v1 and the changes to v2 will be lost unless you also save v2 as a BSV file before you restore and import it again, then publish again.

Thanks for the info.

kklosson

There is some discussion earlier in this thread about using Navicat to compare database changes. Having explored this, I find it very useful and it gives me more confidence when building and deploying. I will outline the basic steps below, though most of you could likely figure it out on your own.

Create a new database. I called mine basdbtest_current.
Select all tables in the basdbtest database and drag them over the top of basdbtest_current. You will be prompted to copy structure, data, or both - your choice. Note that you have to close and reopen the basdbtest_current database to see the copied tables. You now have a baseline database for comparison.
Under Tools, select Structure Synchronization. Set basdbtest as the source and basdbtest_current as the target and press the Compare button. When finished, you get a good list of all database changes as you see below.

After deployment, you can repeat everything to create a new baseline for your next session. You can also simply run the queries in the compare window to alter the baseline table accordingly. For now, I intend to do this for basdbtest during development and basdb right after publishing a new BSV.

hpl123

kklosson wrote
There is some discussion earlier in this thread about using Navicat to compare database changes. Having explored this, I find it very useful and it gives me more confidence when building and deploying. I will outline the basic steps below, though most of you could likely figure it out on your own.

Create a new database. I called mine basdbtest_current.

Select all tables in the basdbtest database and drag them over the top of basdbtest_current. You will be prompted to copy structure, data, or both - your choice. Note that you have to close and reopen the basdbtest_current database to see the copied tables. You now have a baseline database for comparison.

Under Tools, select Structure Synchronization. Set basdbtest as the source and basdbtest_current as the target and press the Compare button. When finished, you get a good list of all database changes as you see below.

After deployment, you can repeat everything to create a new baseline for your next session. You can also simply run the queries in the compare window to alter the baseline table accordingly. For now, I intend to do this for basdbtest during development and basdb right after publishing a new BSV.

Nice 🙂

« Previous Page Next Page »