> But what if you need read/write access? How transactional would > that be?
In the SAP example cited, write access is not allowed. By that, I mean that granting users (besides those used by the SAP/R3 system) write access to the database voids your support contract. How's that for side stepping the question? :) I know of no practical problems as far as transactions go. If an error occurs in the linked server, it bubbles up and rolls back the transaction in SQL Server. I do not know how developers generally handle manual rollbacks. They could be managed programmatically -- if not gracefully. I can understand why cross-database and cross-server queries are not supported -- it's that whole durability thing, right? :) It would probably be difficult, if not impossible, to guarantee that you could restore the two databases back to the same point. In fact, unless the system was bought down for backups, you're database backups would be out of sync. This brings me back to my original point. Most of what I've seen done is, as I said, read only. The data in most of the databases is wiped and restored regularly, or it's used for reporting purposes. We only care about the durability of the application database, and, in general, we're only backing up the application database. Ben Rogers http://www.c4.net v.508.240.0051 f.508.240.0057 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Gold Sponsor - CFHosting.net http://www.cfhosting.net Message: http://www.houseoffusion.com/lists.cfm/link=i:4:185017 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
