View might cause corruption?
-
My company's reporting software combines data from multiple sources such as point of sale, inventory, accounting, payroll, etc.. Where possible, we provide our customers with a direct connection interface against the datasource, usually SQL Server. All we require is read only access to the vendor database. A long time customer recently switched to a new inventory system. Our connection to this system uses a view created in another sql server database (usually the master) residing on the same server/instance. The customer asked the IT department for help in getting the view created, and setting up a readonly sql server login to pull the data. This started a lot of questioning, and the next thing I know, the customer forwards me a response from the inventory vendor advising against using this view against their database. Why? Without quoting, they stated that due to the possibility of upgrades or structure changes, there was a possibility of corruption to the source tables. It is my understanding that by design, there is zero chance of a view causing corruption to the source tables. At worst, it would fail or produce incorrect results. I know I don't know what I don't know, which is why I am asking here. (and Google isn't coming up with any usable results) Am I wrong? To me this just seems like a scare tactic from the other vendor to charge for custom work.
"Go forth into the source" - Neal Morse
-
My company's reporting software combines data from multiple sources such as point of sale, inventory, accounting, payroll, etc.. Where possible, we provide our customers with a direct connection interface against the datasource, usually SQL Server. All we require is read only access to the vendor database. A long time customer recently switched to a new inventory system. Our connection to this system uses a view created in another sql server database (usually the master) residing on the same server/instance. The customer asked the IT department for help in getting the view created, and setting up a readonly sql server login to pull the data. This started a lot of questioning, and the next thing I know, the customer forwards me a response from the inventory vendor advising against using this view against their database. Why? Without quoting, they stated that due to the possibility of upgrades or structure changes, there was a possibility of corruption to the source tables. It is my understanding that by design, there is zero chance of a view causing corruption to the source tables. At worst, it would fail or produce incorrect results. I know I don't know what I don't know, which is why I am asking here. (and Google isn't coming up with any usable results) Am I wrong? To me this just seems like a scare tactic from the other vendor to charge for custom work.
"Go forth into the source" - Neal Morse
Having worked for a software vendor in the past, I'm leaning toward scare tactic. The vendor doesn't want to deal with potential performance problems / data inconsistency, etc, so they are covering their A**. One way to handle this is ask the vendor what is their "supported" integration method? You can always build the view against the vendor's recommendation, but look at your support contract and it might put a monkey wrench in the works.
-
My company's reporting software combines data from multiple sources such as point of sale, inventory, accounting, payroll, etc.. Where possible, we provide our customers with a direct connection interface against the datasource, usually SQL Server. All we require is read only access to the vendor database. A long time customer recently switched to a new inventory system. Our connection to this system uses a view created in another sql server database (usually the master) residing on the same server/instance. The customer asked the IT department for help in getting the view created, and setting up a readonly sql server login to pull the data. This started a lot of questioning, and the next thing I know, the customer forwards me a response from the inventory vendor advising against using this view against their database. Why? Without quoting, they stated that due to the possibility of upgrades or structure changes, there was a possibility of corruption to the source tables. It is my understanding that by design, there is zero chance of a view causing corruption to the source tables. At worst, it would fail or produce incorrect results. I know I don't know what I don't know, which is why I am asking here. (and Google isn't coming up with any usable results) Am I wrong? To me this just seems like a scare tactic from the other vendor to charge for custom work.
"Go forth into the source" - Neal Morse
The only time I would even think that a view could cause you trouble is something called a Materialised view, and that's an Oracle thing - not a SQL Server one. Sounds like a scare tactic to me.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
My company's reporting software combines data from multiple sources such as point of sale, inventory, accounting, payroll, etc.. Where possible, we provide our customers with a direct connection interface against the datasource, usually SQL Server. All we require is read only access to the vendor database. A long time customer recently switched to a new inventory system. Our connection to this system uses a view created in another sql server database (usually the master) residing on the same server/instance. The customer asked the IT department for help in getting the view created, and setting up a readonly sql server login to pull the data. This started a lot of questioning, and the next thing I know, the customer forwards me a response from the inventory vendor advising against using this view against their database. Why? Without quoting, they stated that due to the possibility of upgrades or structure changes, there was a possibility of corruption to the source tables. It is my understanding that by design, there is zero chance of a view causing corruption to the source tables. At worst, it would fail or produce incorrect results. I know I don't know what I don't know, which is why I am asking here. (and Google isn't coming up with any usable results) Am I wrong? To me this just seems like a scare tactic from the other vendor to charge for custom work.
"Go forth into the source" - Neal Morse
A view in SQL Server can corrupt the underlying table, as changes to the view will change the table. However, your explanation seems to take care of that (read only user, etc.). I have not worked with views for a while so I do not remember all the what will happens. Good luck.
-
My company's reporting software combines data from multiple sources such as point of sale, inventory, accounting, payroll, etc.. Where possible, we provide our customers with a direct connection interface against the datasource, usually SQL Server. All we require is read only access to the vendor database. A long time customer recently switched to a new inventory system. Our connection to this system uses a view created in another sql server database (usually the master) residing on the same server/instance. The customer asked the IT department for help in getting the view created, and setting up a readonly sql server login to pull the data. This started a lot of questioning, and the next thing I know, the customer forwards me a response from the inventory vendor advising against using this view against their database. Why? Without quoting, they stated that due to the possibility of upgrades or structure changes, there was a possibility of corruption to the source tables. It is my understanding that by design, there is zero chance of a view causing corruption to the source tables. At worst, it would fail or produce incorrect results. I know I don't know what I don't know, which is why I am asking here. (and Google isn't coming up with any usable results) Am I wrong? To me this just seems like a scare tactic from the other vendor to charge for custom work.
"Go forth into the source" - Neal Morse
Name and shame the vendor, they are feeding you a line of bullshit. Your understanding is absolutely right, a read only connection to the database cannot corrupt the data. It can seriously affect performance if the view is badly designed but then you already know that!
Never underestimate the power of human stupidity RAH
-
Name and shame the vendor, they are feeding you a line of bullshit. Your understanding is absolutely right, a read only connection to the database cannot corrupt the data. It can seriously affect performance if the view is badly designed but then you already know that!
Never underestimate the power of human stupidity RAH
Thanks for the feedback! The other vendor acknowledged that the statement was incorrect and will be providing the customer with the resources required (a readonly login + new views) to extract the requested information. Furthermore, they are making these changes standard for all of their customers...a resolution that works for everybody.
"Go forth into the source" - Neal Morse