Using 7.9.9. We have a gateway for a Customer’s project. On it we have the live production version and a TEST version which is were we work on our changes before pushing them through.
Since sometimes thing change in TEST or just poked and prodded, when a real bug comes through, usually first thing we do is delete the TEST version, make a copy of the production, call it TEST, and then point it to the development database (in the gateway settings).
Recently, one of the customers QA folks was giving training to other employees on the TEST version but saw data from the same day and realized it was coming from production. He saw one of the test procesess he ran too had now made it into the production database. Luckily it was caught early.
My coworker took a look - the gateway information on the project pointed it to the development database as the default db. The project properties when in Designer pointed to the development database. My coworker downloaded the project and he said when he did so it was pointing to the right database. Though he also did open designer, do a save/push on the TEST system and I have to imagine that was before he downloaded a copy but I am not sure. I do know he didn’t make any change to the project properties and strictly did a Save/Publish. I asked if he say Global Props as one of the items to push as thats (where I thought) the default db is saved and he said he didn’t see that as a selection to push.
All our query bindings and system.db.* do not specify a database so that we can keep the production vision application and production database completely separate from the test app and test database.
Any ideas on how this may have occurred? And just generally speaking, any ideas on perhaps a better practice/methodology for handling this such that this just never occurs? We are lucky it was caught early this time, I want to make sure next time we have to fix a live bug, we don’t accidentally do it again when we make a copy to the TEST project.
I can't really speak to much else, but I would think this is the exact opposite of what you would want to do. I always specify the database to use so that the application isn't "defaulting".
Then someone can't change any of my scripts by accidentally changing the projects default db. Of course my setup also has multiple production databases, so perhaps that changes things a bit for me.
This also makes the code look very similar between different scopes, as you would always need to specify the database connection in a gateway scope.
I would guess there's a mistake on this score somewhere. Possibly in a named query?
FWIW, I think you are living dangerously. Set up a proper test environment (separate gateway) where the hostname or IP address of your database is occupied by an offline copy of the production DB.
Yea I will suggest it as a recourse. This whole system is on our customers computers (production and test as they have QA who want to test changes before pushing) so I guess it will be up to them if they want to spare another VM or computer for our testing. I think though this is 100% the best way forward.
Yea this was made way before my time and from the design seems like it was made with the idea of defaulting being the right way to go to easily make a copy of the production app that will work as a testing app. Obviously that may have been a mistake lol.
Maybe if this thing used a named query instead of SQL creation via strings everywhere lol. But yea. Once I connect I plan to do a Control+F for the production database name.
Otherwise though I am still going to heavily push a second server for development gateway.
They don’t want to have to pay for another license on a separate computer just for the dev system so never mind this will not be the route I go down. In a perfect world