Walaa wrote:
I'm not sure I understand you, sorry
Walaa wrote:
I can't understand this phrase, are you speaking about multiple usages of the component in the same application, to different catalogs.
Yes, that's where it's going at - One application, multiple projects, one component being used across these projects.
I hope i can clarify this a bit by a practical example
Lets say i have an application, which consists of 3 different projects, project A, project B and project C (all being DLLs when they get compiled). Project A connects to database DbA, project B to database DbB and project C to database DbC, every project uses its own LLBL generated DAL.
Now, a monitoring project, call it component M, comes into play. It is supposed to do monitoring and store status in its own tables, called T1 and T2, but as being a component, it's not meant to have its own database, but rely on its tables T1 and T2 being present in the database the current project uses.
For our example: A uses M, B uses M and C uses M, therefor, T1 and T2 have to be present in DbA, DbB and DbC.
Problem is: T1 and T2 where originally in database DbM, so on generating the DAL for M, DbM is hardcoded onto the DAL. So far so good, if M was only used in A, i would make a rename from DbM to DbA. But as M is used in A, B and C, i can't make a rename from DbM to DbA, DbM to DbB and DbM to DbC, can i? If i was a piece of software, i'd find that rather confusing
(As hopefully this post isn't
)
Question is: Is there some why to use the catalog renaming in code somehow? Can i maybe tell M to use the catalog from the connection string of the project we're currently in (that being A, B or C)?
Best regards,
Alex