This seems like a good idea but the thing that makes me uneasy, looking at your properties mock-up above, is the server field. This effectively hard codes the server name into the application which makes code portability non-existent. Think how this will affect moving an application from a development environment into a live environment or replicas spread across servers in different cities or countries. The last thing you would want is a replica in Hong Kong trying to do a @dblookup to a database in London.

I think this idea has merit if the server field could be blank which would force @dblookup and @dbcolumn formula using the Data Connection to use the current server.

Sorry Patrick. I don't like this idea, at least not in the way it is proposed. By making the data connection a design element you are essentially consigning every database that inherits its design linking to the same physical database. In many cases the external databases needsto vary (e.g. Development v QA v Production).

With what we already have today is possible to define a Data Connection as a data document and then have the code refer to the data in the connection document. This allows every instance of a database to have its own defeinitions of where the external database reside and even allow the definition to specify the location using either replica ids or specific server/fileprarhs.

I think your connection works as a layer between the program and the reference of other db. Even with this feature, you cannot expect all the programmers to take this extra effort. Moreover, if it is supposed to be a practice standard, you can actually do it with some profile views without introducing a new design element.

I agree that this is a hassle, and something to address it would be cool. I don't think that this is the solution though, sorry.