8.1 testing, sync database?

hpl123

Hi all,
Tinkering with 8.1 and the new option to allocate a new DB (+ no LIVE/TEST etc. prefixes) for testing a app is great and I wonder if it´s as easy as synchronising data between the 2 DB´s i.e LIVE + TEST DB and then theoretically I would have all data from the LIVE DB in the TEST DB? Is there anything in particular I need to do or think about when doing this? Any particular table/field differences between a LIVE and TEST DB?

Thanks

PointsWell

The immediate thing that springs to mind is the AIM ID field which is incremented across the AIM environment not just the table or database.

ACDC

If its an occasional sync, then dump the relevant tables to a .sql file and use a good text editor to FIND and REPLACE Table names in the .sql file. Also the DB name needs to be replaced with target DB name. Then restore the .sql file.
(You don't need a separate DB to do this)

The immediate thing that springs to mind is the AIM ID field which is incremented across the AIM environment not just the table or database.

to prevent a conflict of ID no's , set the bas_idgen table on both sides to a number that ensures no conflict,
Example: basdbtest bas_Idgen, make it start at 1 000 000

IMHO, running a separate DB comes with risks of inadvertently overwriting the table with data from another app. Having the BSV name as part of the published tables always guarantees uniqueness. This may sound crazy but believe me, migrating to new servers and restoring databases, this could happen. I have been saved in the past because of this uniqueness. I asked support to include an option to append a name to the separate database table naming, but they were NOT interested

hpl123

Yeah the ID field is of course a problem but do we rrally need it? Is it a ID used in the db i.e unique id for table etc. relations? Ideally I would just want a feature in Aware that does this for us i.e copy live data to a test db where we could then test stuff properly 🙂

BLOMASKY

Guys, I am using MSSQL and love the fact that I can have a separate test DB with the SAME file names.

As someone already mentioned, Aware has 2 BAS_IDGEN tables. one in the main awareDB and one in the awareTestDB. So it is important to make sure you set the max_ID to a high enough number to not over write the data

After the users do some "good" work in the live data, I make a DBBackup and just restore it over the testDB. (When I am developing on my laptop disconnected from the network, I do the same thing, I backup the live data and restore it to my test DB.

I do not understand why there would be a desire to prefix the table names. This would break all stored procedures / views and not allow you to copy to/from Live/Test. There is no way a table would be overridden, since if you tried to create a BO in aware that had the same name as some existing table, you would get an error when you went to testing mode.

Bruce

BLOMASKY

hpl123 wrote
Yeah the ID field is of course a problem but do we rrally need it? Is it a ID used in the db i.e unique id for table etc. relations? Ideally I would just want a feature in Aware that does this for us i.e copy live data to a test db where we could then test stuff properly 🙂

If you plan to "Use" the database and create new records then you DO need the max_ID set to a number that will NOT create duplicates in any table. (of course, my wish would be that Aware supported identity fields in the backend database and therefore, would never need to use the Max_ID. This would eliminate a lot of contention for a 1 row table.

Bruce

BLOMASKY

ACDC wrote
IMHO, running a separate DB comes with risks of inadvertently overwriting the table with data from another app. Having the BSV name as part of the published tables always guarantees uniqueness. This may sound crazy but believe me, migrating to new servers and restoring databases, this could happen. I have been saved in the past because of this uniqueness. I asked support to include an option to append a name to the separate database table naming, but they were NOT interested

If the Test and Production DB are JUST for your aware app, why would you think table names would be overridden? Who / what would be creating tables in this db? This would be no diff from using just 2 dbs, the aware and the awaretest db.

Because the licensing, max_ID , my application code is all stored in the awaredb, I want to NEVER touch that with my data where I might do a "whoops" and corrupt it. Its always easy to restore my application data. Or, if I have to move to a new, licensed aware installation, I can restore my prod and test db without affecting the aware setup.

BTW, another trick I found, is by keeping this a separate db, I can have 2 different apps or machines "share" the data by first letting aware create the "New, Empty" DB, shutting down Aware, restoring my db into that one and it now has all the same test data.

Bruce

ACDC

If the Test and Production DB are JUST for your aware app, why would you think table names would be overridden? Who / what would be creating tables in this db?

The risk only exists when restoring or moving (migrating) data to new servers, or recovering from some kind of system crash. For example, if you have 10 BSV's on a single server based on the CRM sample (10 different databases), the only thing separating the table names is the database name. If you happen to be moving or copying a single table data from a backup and inadvertently move it into the wrong database you are stuffed. (If a formal restore is being used on a .sql file then the database name is preserved) but using DB tools that let's one selectively move tables around is where it starts to become a risk

In your case , using stored procedures in the way you do, it makes sense. I can think of some other use cases where it also makes sense. But as a developer with multiple customers with similar BSV's I would still like the option of adding the BSV name to the separate DB