I am researching if Dynamic Data can work with N databases (within the
same SQL Server 2008 instance).
yes and no.
If you create individual connections for each database in question, it
can be worked out. If you are trying to make a single point of update?
No. Actually, not quite true, as you can link the databases and make it
appear to be a single point of entry, but that is trickery on the SQL
Server side.
Joining data? Not presently, without the "kludge" mentioned above. And,
this might not be supported by the drag and drop bits, meaning you are
going to possibly be handcoding something that is designed as a time
saving measure (losing time in the process).
I found
http://blogs.msdn.com/davidebb/archive/2008/12/11/using-dynamic-data- wi
th-multiple-databases.aspx , but it doesn't address joining data from
different databases. I would love to use dynamic data but this is a
show stopper for me.
It is not going to happen due to the current nature of the project.
Linking up data from disparate databases is a huge undertaking. While
Microsoft may eventually do something like this, it falls outside of the
scope of the current dynamic data initiative.
Dynamic data, as it sits right now, is aimed at exposing a database
easily. You can expose multiple databases in a single "app", but linking
the data together is a lot harder problem than it might appear.
Having said this, I am not sure dynamic data is the best solution to
your problem.
Any ideas how this could possibly be achieved? Perhaps database
views?
Without linking up the data, which has its own issues, you are not going
to do this. In addition, i am not sure thge current tooling will support
the linked databases.
You might kludge around this with stored procedures that call the other
databases (or other objects), but then you are creating a maintenance
nightmare so you can drag and drop an admin tool.
Peace and Grace,
