Symptoms

Incorrect service instance resolution
 

Diagnoses

Background:
We have identical databases in our production and test environments, and the SQL Server service instance has previously been deployed from test into production environment, along with a set of SmartObjects, which work correctly. When doing the deployment there was a naming conflict, where the database and a SharePoint site had the same name "test". This was solved by renaming the SQL service instance in the package and deploy tool into "testDB".

So, currently there are the following relevant service instances in the production and test environments:
- Production
- SQL Server service instance. (Name: testDB, GUID: xxx-xxx-xxxx-ac207faa)
- SharePoint site service instance. (Name: test, GUID: xxx-xxx-xxxxx-f23f65e8)
- Test
- SQL Server service instance (Name: test, GUID: xxx-xxx-xxxx-ac207faa)
The problem:
We have created more SmartObjects in the test environment, to be used by the newly implemented forms and views. When we try to deploy these to the production environment, the package and deploy tool correctly notices that the service instance they depend on already exists. We then select the "Use Existing Service Instance" option. When the deployment tool tries to deploy the SmartObjects, the following error occurs for each of them:
System.Exception: Dependency could not be created: System.Exception: Dependency could not be created. Parent does not exist in this environment. Check Data property of exception.

The problem is likely caused by the package and deploy tool comparing the service instances incorrectly. It seems that when we try to deploy the SQL service instance with the name "test", it mistakes the SharePoint site service instance with the same name for the already existing instance. There does not seem to be any option forcing the deploy tool to match the service instances by GUIDs rather than names.
 

Resolution 
We have created more SmartObjects in the test environment, to be used by the newly implemented forms and views. When we try to deploy these to the production environment with the package and deploy tool, we created a replica of the Db and changed its name from "test" and "testDB", then we used the current Service instance and pointed it to the new DB.
We redeployed the package to the test server by using the current service instance, along with the SMOs/Views/Forms and then selecting overwrite and then changing the system name before deploying. After deploying we created a new Package and deployed it to the Production server and everything deployed and worked 100%.