How can we help you today? How can we help you today?
jfennell
Hi, I think I have tracked this problem down to a problem in a view referenced in the vwEMAILS_INTERACTIONS view that's causing that view not to build properly when SQL Source Control executes its update script. Now that the Beta version (which I just installed) allows access to the actual SQL script that it's executing when trying to do the updates (THANK YOU, THANK YOU, THANK YOU!!), I was able to narrow down the problem to the following statement: EXEC sp_refreshview N'[dbo].[vwEMAILS_INTERACTIONS] Since the view that was being modified by the SQL Source Control "Get Latest" is one of the views underlying vwEMAILS_INTERACTIONS, SQL Source Control tries to refresh it. Unfortunately, there is currently an error in the code for the vwEMAIL_INTERACTIONS view (caused by a different underlying view in the select statement of vwEMAIL_INTERACTIONS). That error causes the sp_refreshview call to fail, which causes the "Get Latest" update to fail and roll back. So it looks like SQL Source Control is functioning fine, including rolling back when it encountered the error. In fact, I guess you could say it functioned better than fine since it caught an error that apparently wasn't caught by one of our developers. :oops: Now on to a fix. I'll comment on the post again once it's all completely resolved, but I'm pretty certain that SQL Source Control is not to blame here. / comments
Hi, I think I have tracked this problem down to a problem in a view referenced in the vwEMAILS_INTERACTIONS view that's causing that view not to build properly when SQL Source Control executes its ...
0 votes
Stephanie, Thanks for the quick response. The linking isn't a big deal at all, since as you mentioned it is only a one-time thing. It was just a surprise that it didn't show up on all users after one user did it, but now I see how things are working. We've been using the source control repository as a "go-between" for our integration environment, which is where we're seeing the discrepancies. Here's a description of the lifecycle we're trying to use for both code and SQL database changes: 1) Developer makes a change locally and tests it locally. 2) Change is committed from developer's local system to SVN repository. 3) Developer then logs onto the integration server and retrieves changes from the repository using a "Get Latest" 4) Developer builds the new application with the changes and tests that the changes integrated successfully with all other developers' changes. I know it's kind of an "unorthodox" way to use the source control repository, but it forces all of our developers to make sure things are in the repository. It's also given us a VERY smooth way to get database changes applied in our integration environment. Since the environment doesn't allow direct connections to the database server from an external network, passing them through the repository like this works like a charm and for the most part hasn't caused any problems. In fact, the only time I noticed an issue with inconsistencies between users is related to my other post from today (subject: Error Applying Changes from Get Latest). I'll review the recommendations post and see what else I come up with for solutions too. I know that if all developers logged into the same for committing database changes and performing builds we wouldn't have any "user-specific" discrepancies; that might be an option if it becomes a big problem, but I doubt it will. And hey, it's only just today released in beta! I'm sure the support for the shared database model will improve! Thanks again for the great work!! / comments
Stephanie, Thanks for the quick response. The linking isn't a big deal at all, since as you mentioned it is only a one-time thing. It was just a surprise that it didn't show up on all users after o...
0 votes
Thanks for the information, David. I just want to clarify your information by asking another question. Will customers be able to purchase SQL Source Control separately, or will it ONLY be available with the SQL Developer or SQL Toolbelt bundles? It would be a big mistake, in my opinion, not to offer a purchase option that allows for the purchase of just the essentials needed for SQL Source Control. You are filling a HUGE need in the development community with this tool, and filling it quite well I might add. If my client has a team of 10 developers who just need to be able to check things in and out of the repository with SQL Source Control, and he can't afford 10 copies of one of the bundles, it's going to be a hard sell to convince him he needs SQL Source Control. I'd strongly recommend a "standalone" flavor of SQL Source Control, if that's at all possible, or at least a version that contains only the minimum parts of SQL Compare that are required to make Source Control work. Heck, a bundle of SQL Compare and SQL Source Control for say $595 would be much more palatable than requiring a purchase of $1,295 per seat. Please consider this so you don't price yourself out of a lot of business. Once people see the quality of your tools, you'll get a lot of upgrades as well!! Peace, / comments
Thanks for the information, David. I just want to clarify your information by asking another question. Will customers be able to purchase SQL Source Control separately, or will it ONLY be available...
0 votes