Hello all,
We're considering something very radical and risky. I'm trying to get a good feel for the depth of negative repercussions.
We've been using AC for over a year now and it has turned out pretty well. We have a legacy business system that still handles all our accounting/inventory/purchasing and we're trying to get rid of it. (AC data is hand entered.....) One of the reasons we went with AC was possible integration with VisionCore and using it to replace our business system.
We've struggled to get VC tested and partially up and running with the way we do business. (Not entirely relevant to an AC forum, but part of the backstory.) As a result of the testing, we now have valid business data in VC. This is important.
We've not been able to go live with the AC - VC integration bridge. We have live data in both systems and would end up with a mass of duplicate data as the PKs in several tables would not match. Data synchronization is two way on some tables, one way on others. It seems like the integration bridge is designed more for existing VC customers that want to add a website to their systems. We're trying to do the exact opposite. The VC folks have been nice enough to try and help us with a merge, but that has taken several months and we still don't have anything to show for it. We're nearing the end of our summer slow season and need much more significant progress. This brings me to our radical thoughts and question for the AC community.
We are considering blowing away our existing AC tables and building a new site, letting the VC integration bridge build the catalog and contents. We'd lose all of our customer data and order history. We've got all that data in our existing business system. The vast majority of our customers are anonymous so they may not notice the difference. We'd have a handful of customers that would need to rebuild their customer accounts and would loose their order history. The only alternative would be rebuild from scratch and try importing existing ac_orders* table data. If I only import the order* tables, it would break referential integrity with several other tables (ie. orders.orderid,orderitems.parentitemid, etc..) This could be a *bad plan* though.
So my question to the forum, start completely from scratch and deal with the customer fallout or try importing existing ac_orders* data? Trying to import existing data seems like a one way trip to data hell to me.
Thanks for your opinion.
Rebuilding and starting over (related to VisionCore)
Re: Rebuilding and starting over (related to VisionCore)
Resurrecting an old thread of mine.
We're just about done spinning our wheels trying to get AbleCommerce and VisionCore to communicate with each other. We've gone nowhere real slow.....
At this point, we cannot recommend AbleCommerce - VisionCore integration in case anyone is considering it.
Fast forward a few months now. VC helped us import our AC data in to VC, but there were a lot of holes and errors in the data. Repairing those holes/errors have generated more than a few primary key discrepancies between our development and live sites. Subsequent testing of the data was a mess. Two steps forward, one step backward.
For one last test, we want to purge our AC development db of all categories, inventory, customers, orders, order items, payments, etc... Essentially leave a blank shell of a site. We're running 7.0.5. Is there an easy way to purge all the appropriate tables or an easy way to generate a new db with only our basic site configuration information? (ie. re-install??)
Suggestions please.
We're just about done spinning our wheels trying to get AbleCommerce and VisionCore to communicate with each other. We've gone nowhere real slow.....
At this point, we cannot recommend AbleCommerce - VisionCore integration in case anyone is considering it.Fast forward a few months now. VC helped us import our AC data in to VC, but there were a lot of holes and errors in the data. Repairing those holes/errors have generated more than a few primary key discrepancies between our development and live sites. Subsequent testing of the data was a mess. Two steps forward, one step backward.
For one last test, we want to purge our AC development db of all categories, inventory, customers, orders, order items, payments, etc... Essentially leave a blank shell of a site. We're running 7.0.5. Is there an easy way to purge all the appropriate tables or an easy way to generate a new db with only our basic site configuration information? (ie. re-install??)
Suggestions please.
Re: Rebuilding and starting over (related to VisionCore)
Hi Eric,
I guess no one in Able forums was able to give you any suggestions or advice probably because no one has really been able to grasp the actual problems you are facing. As to why an intermediate bridge can't be written to communicate between AC and VisionCore flawlessly is not clear. There must be technical challenges I am sure because of the mismatch of ids and keys between two systems, but after-all you are able to match the records manually on some criteria; so why not the same criteria gets implemented in code? As far IDs why can't either custom fields in AC be utilized to store the ids from VisionCore or custom fields in VisionCore be used to store IDs from AC? Why you have come to such a drastic conclusion of wiping out your AC data and start afresh. How is this going to help after all? Will the things work in sync after that? If so what prevents you from 'fixing' the current data and moving forward? What are the challenges involved in trying to fix the current data to make it compatible with VisionCore?
Thanks
I guess no one in Able forums was able to give you any suggestions or advice probably because no one has really been able to grasp the actual problems you are facing. As to why an intermediate bridge can't be written to communicate between AC and VisionCore flawlessly is not clear. There must be technical challenges I am sure because of the mismatch of ids and keys between two systems, but after-all you are able to match the records manually on some criteria; so why not the same criteria gets implemented in code? As far IDs why can't either custom fields in AC be utilized to store the ids from VisionCore or custom fields in VisionCore be used to store IDs from AC? Why you have come to such a drastic conclusion of wiping out your AC data and start afresh. How is this going to help after all? Will the things work in sync after that? If so what prevents you from 'fixing' the current data and moving forward? What are the challenges involved in trying to fix the current data to make it compatible with VisionCore?
Thanks
Re: Rebuilding and starting over (related to VisionCore)
Thanks for the response and good questions. I'll answer as best I can without writing a novel.
There are three dbs involved here:
Live AC site: Ongoing business
Dev AC site: A copy of live site data. Data is now a few months old.
VC Server: ::sigh:: Contains some live data and a bunch of crap data. This is one of the key problems as accounting has been using VC in a limited fashion to handle banking and purchasing. Their call and I cannot dump the VC data.
Bridge:
The bridge uses some combination of primary keys and custom fields for synchronization. Category, inventory, customer, order, order items, order payments data is bi-directional.
Background:
The VC folks helped us do an import of live AC data, including categories, inventory, customers, orders, payments, etc.... The intent was to help get both AC and VC set up to run the bridge. At first glance, the data looked good but the more we dug in to it, the more problems we found. Turning the bridge on was disasterous as it began to delete inventory data in both systems. (Anything marked as a kit was deleted and there were problems with options/variants.) Additionally, we found the field mapping to be less than accurate. I'd call these critical bugs and we've been waiting on fixes for a few months now.
Ultimately, we want to be able to connect the bridge to the live AC site. However, due to the data carnage in the dev site, there are wildly different primary keys between Dev AC and live AC. This is the key issue. I've tried to reconcile the two sites using SQL Data Examiner, but have yet to succeed. There are a lot of data dependencies to resolve. Given the current mess of data, my level of confidence of any data updates would be low. I could ask VC to try repairing the data, but my confidence in that result would be even lower.
So... If miracles happen and VC can get the bridge issues resolved, I need to find a way to move forward. One solution would be to purge all of the data out of the Dev AC site and let the bridge rebuild everything. Once that is done and tested, *replace* the live site db with the dev site and switch the bridge to the live site. It's a pretty severe move, but would ensure the overall data structure would be solid. We'd lose all the the order data and customers would lose all of their order history from the live site. We've got all of that backed up and could continue processing their orders. That would cause some major grumbling, but the overal company performance and service gains we make should outweigh the short term loss there.
The big question:
The bottom line question is what is the easiest way to purge site data and get back to a brand new dev site? Would a re-install be easiest? VC is supposed to have an update to the bridge this month. When we get it, I want to at least test a full scale push of the data from VC to dev AC and see if I can get clean data.
<soapbox mode on>
Learning points for all:
- Never mix live and test data. Senior management (over my head) made the call and I allowed it. I knew it could lead to disaster and now I'm dealing with it. Should have been willing to fall on my sword for that. My bad.
- There was a desire to avoid redundant data entry between live data and test data during testing. This lead to the decision to test in the live site. During a major deployment, chances are there will be redundant work to test any new system. That's the way it is!
<soapbox mode off>
There are three dbs involved here:
Live AC site: Ongoing business
Dev AC site: A copy of live site data. Data is now a few months old.
VC Server: ::sigh:: Contains some live data and a bunch of crap data. This is one of the key problems as accounting has been using VC in a limited fashion to handle banking and purchasing. Their call and I cannot dump the VC data.
Bridge:
The bridge uses some combination of primary keys and custom fields for synchronization. Category, inventory, customer, order, order items, order payments data is bi-directional.
Background:
The VC folks helped us do an import of live AC data, including categories, inventory, customers, orders, payments, etc.... The intent was to help get both AC and VC set up to run the bridge. At first glance, the data looked good but the more we dug in to it, the more problems we found. Turning the bridge on was disasterous as it began to delete inventory data in both systems. (Anything marked as a kit was deleted and there were problems with options/variants.) Additionally, we found the field mapping to be less than accurate. I'd call these critical bugs and we've been waiting on fixes for a few months now.
Ultimately, we want to be able to connect the bridge to the live AC site. However, due to the data carnage in the dev site, there are wildly different primary keys between Dev AC and live AC. This is the key issue. I've tried to reconcile the two sites using SQL Data Examiner, but have yet to succeed. There are a lot of data dependencies to resolve. Given the current mess of data, my level of confidence of any data updates would be low. I could ask VC to try repairing the data, but my confidence in that result would be even lower.
So... If miracles happen and VC can get the bridge issues resolved, I need to find a way to move forward. One solution would be to purge all of the data out of the Dev AC site and let the bridge rebuild everything. Once that is done and tested, *replace* the live site db with the dev site and switch the bridge to the live site. It's a pretty severe move, but would ensure the overall data structure would be solid. We'd lose all the the order data and customers would lose all of their order history from the live site. We've got all of that backed up and could continue processing their orders. That would cause some major grumbling, but the overal company performance and service gains we make should outweigh the short term loss there.
The big question:
The bottom line question is what is the easiest way to purge site data and get back to a brand new dev site? Would a re-install be easiest? VC is supposed to have an update to the bridge this month. When we get it, I want to at least test a full scale push of the data from VC to dev AC and see if I can get clean data.
<soapbox mode on>
Learning points for all:
- Never mix live and test data. Senior management (over my head) made the call and I allowed it. I knew it could lead to disaster and now I'm dealing with it. Should have been willing to fall on my sword for that. My bad.
- There was a desire to avoid redundant data entry between live data and test data during testing. This lead to the decision to test in the live site. During a major deployment, chances are there will be redundant work to test any new system. That's the way it is!
<soapbox mode off>
Re: Rebuilding and starting over (related to VisionCore)
OK. So currently its the Dev AC site that has bad data and that you want to either clean up or fix.
Why don't you just restore a backup of the AC Live database to the AC Dev database? I guess your Dev site also contains updates from VC bridge? Can those updates be restored/recreated again on the Dev site after it has been refreshed with Live site's database?
Why don't you just restore a backup of the AC Live database to the AC Dev database? I guess your Dev site also contains updates from VC bridge? Can those updates be restored/recreated again on the Dev site after it has been refreshed with Live site's database?
Re: Rebuilding and starting over (related to VisionCore)
If a simple restore would do the trick, I'd give it a shot in a heartbeat. No problems there.
The problem I am seeing is the data the bridge ate/modified now have new ProductIDs and VCId's.(internal VC code.) Since these are primary keys and used in multiple tables, any restore of live data will have different PKs. Now the bridge will see different keyfields than before and I'm concerned I could end up with dupe data. Additionally, since some of the inventory items affected were used in previous orders, I'm not sure we'll keep referential integrity after the update. Might be OK, but there's a lot of data to dig through to confirm.
If you think I'm off my rocker and MS-SQL is smart enough to handle that, that's OK. I'd appreciate the feedback good or bad. Otherwise, I'm still trying to work out the cleanup of the AC site.
The problem I am seeing is the data the bridge ate/modified now have new ProductIDs and VCId's.(internal VC code.) Since these are primary keys and used in multiple tables, any restore of live data will have different PKs. Now the bridge will see different keyfields than before and I'm concerned I could end up with dupe data. Additionally, since some of the inventory items affected were used in previous orders, I'm not sure we'll keep referential integrity after the update. Might be OK, but there's a lot of data to dig through to confirm.
If you think I'm off my rocker and MS-SQL is smart enough to handle that, that's OK. I'd appreciate the feedback good or bad. Otherwise, I'm still trying to work out the cleanup of the AC site.
Re: Rebuilding and starting over (related to VisionCore)
WylieE wrote:Resurrecting an old thread of mine.
We're just about done spinning our wheels trying to get AbleCommerce and VisionCore to communicate with each other. We've gone nowhere real slow.....
Fast forward a few months now. VC helped us import our AC data in to VC, but there were a lot of holes and errors in the data. Repairing those holes/errors have generated more than a few primary key discrepancies between our development and live sites. Subsequent testing of the data was a mess. Two steps forward, one step backward.
I don't know if this is an absolute no-no, but I felt compelled to post an update to our thread.
We've burned close to two years off and on trying to get VisionCore to work. We're done. No more wasted time. It has significant core issues (bills showing paid without payment????, the search tool's broken???
) that have never been consistently or reliably resolved. We've averaged one hotfix every couple weeks and multiple support threads a week trying to get it to work. Any confidence in the data is long gone. Anyone interested in VisionCore for an ERP/accounting solution would be advised to look elsewhere. Don't go down that road.