Forgive me if I've misinterpreted your need, but if you won't be having cross database relationships to your attachments, wouldn't this best be modelled as what it is: an abstract attachment service perhaps via a web service type interface? Used by lots of applications, you abstract out the implementation (ERAttachment) and in the future can implement it using something else....
Mark -- Dr. Mark Wardle Specialist registrar, Neurology (Sent from my mobile) On 19 Mar 2011, at 11:32, David Avendasora <[email protected]> wrote: > Hi all, > > We are currently using ERAttachment in one of our projects. The particular > app it is being used in has it's own DB which resides on a physically > separate server from most of the rest of our Schemas. This app works great, > and handles literally thousands of attachments per day (hence the reason for > it's own physical server and database). > > Now I want to use ERAttachment for another purpose. I want to put it in a > framework that could be used by many, if not all, of our applications, > including the system that currently uses ERAttachment. I can't use the > existing ERAttachment tables in this other, physically-seperate database > because EOF can't do the cross-database fetches it needs to. > > Theoretically, I could have the DBAs setup a cross-database link between the > two databases so EOF could get to the other Schema, but it wouldn't really > make sense from an organizational perspective to have just the attachments on > a different server, that is for a completely different business purpose, > from all the rest of the new framework's tables. > > The problem is that ERAttachment seems to only allow you to configure one > connection dictionary for it. It doesn't appear that you can make use of the > "configurationName" functionality to have different sets of ERAttachment > tables. > > Am I missing how that can be implemented, or is it something that I shouldn't > even be attempting? It seems quite limiting to only allow one set of > ERAttachment tables per application. > > Dave _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/mark%40wardle.org > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
