September 15, 2023 at 1:10 pm
Hello,
I am trying to create an SSDT project (in VS2022) for a database whose objects are primarily owned by a vendor application. This application dynamically creates views that we interface with from 'under-the-hood' tables that have non human-readable names. We have some custom integration code including some procedures, views, and functions, which are in-house additions created by our own team, and this is what I am trying to capture in the project for version control. I created a dacpac of the database and tried using it as a reference (as same database) so that our custom objects can use the reference to build. However, I believe that because our custom objects are in both the project and the reference, I am getting build errors of: "SQL71508: The model already has an element that has the same name xxxxxxxxx" for what appears to be every object in the project. The project name and the reference dacpac are named the same thing, the name of the actual DB.
Is there a way to tell the project or reference to ignore the same objects if they are in the reference? Or would there be a better way to organize this and still enforce build checks to the references? I would like to avoid having to create a manually altered dacpac to reference, removing the custom objects that are in the project in a tedious way, unless that is the only way to make this work.
Any other thoughts or questions are appreciated. I have searched extensively for how to implement something like this where the code is only partially "owned" and the unowned objects need to be referenced in an 'all objects' dacpac and haven't come up with anything.
Thanks!
September 16, 2023 at 2:10 pm
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
September 18, 2023 at 6:09 pm
I can't think of a great way of handling this – sounds like you've considered the possibilities.
Presumably you've discounted the idea of keeping your custom code in a completely separate database and having the vendor database as the reference DB?
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
September 18, 2023 at 6:42 pm
Hi Phil, thanks for the input!
The idea you mention did cross my mind; but yes, I have dismissed it for now as doing such would be a major project. Not only would the code/objects need to be moved, but the application calls these objects "in-database" (e.g., EXEC (stored_procedure_name) statements) in the UI to create custom exports for down-stream integration. These commands could be rewritten to call through a linked server to the separate custom code DB perhaps, but it would be a significant task. Hopefully this makes sense with as little context as I have given.
Unfortunately, my plan is to implement version control for this existing system, that has been around for years before I was employed here, that never had version control set up at all. I'm trying my best to make that happen without kicking the apple cart too hard.
Thanks again!
September 18, 2023 at 7:08 pm
Yeah, that makes sense. But if the code is all in a single DB at the moment, I can't see why a linked server would be needed. Why not a DB on the same server?
I haven't tried this, but maybe using Synonyms within the DB project would make the cross-database code references easier to maintain.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
September 18, 2023 at 7:25 pm
Hi Phil, yes you're correct of course. We could just have a separate DB on the same server.
Using synonyms is an interesting idea. I'll have to think more about that.
Thanks for taking the time and for your input!
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply