Before I get too far out on a limb here...

One application: User Interface

Two back-ends: single user (Access Database) multi-user (MS SQL Server backend)

In my mind the solution is to write a DLL the UI calls upon to get the data (nothing new there)...

Two DLL produced by LLBLGen Pro (One Access and One MS SQL Server)

Write "wrappers" for the combined Access/MS SQL Server so the UI calls the wrapper and based on licensing/configuration the "Wrapper DLL" calls either the Access (Standalone) or the MS SQL Server (Muti-User) DLL for data to be served up.

Example: there would be an Address Table in both databases... the Wrapper DB would be created based on licensing (let's say StandAlone) so during loading, the application database is created hooking the UI to the Wrapper which has created an instance of the a Address object and based on construction parameters aligns itself with the Access LLBLGen Pro DLL for Access...

When there is a request for a StreetAddress to the wrapper it in turn makes a call to LLBLGen generated DLL and passes that back to the UI...

I see alot of work here... but only one UI ... if there was no Wrapper DLL then the UI code is going to contain all the IF/ELSE depending on StandAlone/Multi-User ... I've spent some time looking about in the forums and run into bits here and there, but nothing that directly relates...

Not having much luck in finding the source code to insure I replicate (wrap) what is needed to achieve what I'm considering here. I recall at some point finding documentation as in class reference, but heck if it is in the installed LLBLGen Pro menu area or within the "documentation" PDF or CHM ....

This concept doesn't seem like it should be some "new" idea - seems it would be done all the time. However, our past practices have been to write separate UI/Backends for StandAlone and Multi-User --- I'd like to get away from that maintenance nightmare.

Any suggests and/to pointing in the right direction would be greatly appreciated.

Norman

The idea is simply to create 2 LLBLGen Projects, one targeting Access and the other targeting SQL Server. (The schema should be identical) Please check this thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=7430

Then you should use the Adpater model to generate your code. DataBase Generic project should be the same in both projects. So now you should build, One Database Generic dll, and 2 Database specific dlls.

Use the Database Generic dll through out your application, and at runtime or configure time, you should load the relevant DBSpecific dll.

Please check the following thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=12337

Walaa wrote:

The idea is simply to create 2 LLBLGen Projects, one targeting Access and the other targeting SQL Server. (The schema should be identical) Please check this thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=7430

Then you should use the Adpater model to generate your code. DataBase Generic project should be the same in both projects. So now you should build, One Database Generic dll, and 2 Database specific dlls.

Use the Database Generic dll through out your application, and at runtime or configure time, you should load the relevant DBSpecific dll.

Please check the following thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=12337

Then you should use the Adpater model to generate your code. DataBase Generic project should be the same in both projects. So now you should build, One Database Generic dll, and 2 Database specific dlls.

Use the Database Generic dll through out your application, and at runtime or configure time, you should load the relevant DBSpecific dll.

Please check the following thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=12337

So what you're saying is use adapter methods, with identical schemas... In the code you would note there are two Access Databases (Config and Access in the namespace) ... The Config is logon information and without most of the data collection information that will be in the name space Access... Obviously because the MS Sql version will incorporate Logon as well as data the MS Sql version is the two Access Databases combined.

The reason the Access databases are split is the Access namespace is the "client file" which there is one database per client and the Config namespace is used for logon as well as storing information that is to be completely or partically copied to the "client file" ... additionally the Config database maintains application specific information such as ShowMessageFilter (a toogle to coincide with the user electing to not have a specific messages shown again) - those types of Application specific settings - not something you want in EVERY client file.

I'm not sure I understand the DDL Sql templates reference you provided since it specifically states Access is not useful with the DDL???

Thanks for your reponse and I look forward to additional information if available.

Norman

I wrote something a while ago that used reflection in order to choose the correct dbspecific.dll from a config file. The config file had a db type (Access, FireBird, SQL Server etc.) and an associated connection string. Using the singleton design pattern, each time a DataAccessAdapter was needed, I used reflection to pull it out of the appropriate assembly (datadbspecific assembly). It works just fine. I've switched between access and sql server with no problem.

Seth wrote:

I wrote something a while ago that used reflection in order to choose the correct dbspecific.dll from a config file. The config file had a db type (Access, FireBird, SQL Server etc.) and an associated connection string. Using the singleton design pattern, each time a DataAccessAdapter was needed, I used reflection to pull it out of the appropriate assembly (datadbspecific assembly). It works just fine. I've switched between access and sql server with no problem.

Seth, thanks for you input. I have an "idea" of what you did. It's more of a all or nothing, not that the user is dealing with Access and MS Sql... I'm just not sure how reflection was implemented that you refer to above.

I'm utilizing, not that it can't change, DBUtil for the connection string that is "built/assembled/combined" within a "database class/object" depending on stand-alone vs multi-user (network/sql server)...

I'm also trying to remove the UI code from the picture as far as containing code with a lot of case or if statements... My thought was to have those statements in a "middle tier" or something so in the future if additional database engines were utilized or changed there would be no UI coding to wade through, but only the data specific code in the "middle tier" or I should say "one of several middle components" since LLBLGen is actually a "middle tier" as well.

Norman

I created a "special" xml file that was required when the program started. It specifies which kind of database and the location of the datadbspecific.dll. I then used a static method in a class to create a new DataAccessAdapter from the datadbspecific.dll using reflection. The idea was not to switch between, but to allow the app to work with multiple data stores.

There was no UI code involved with the exception of loading the special file that pointed to the database.

This sounds like what you are looking for doesnt it?

I've attached the "hard" part. I also created a configuration class that was editable via PropertyGrid control so they could switch between db's during run time.

Let me know if this is what you are looking for...

Seth wrote:

I created a "special" xml file that was required when the program started. It specifies which kind of database and the location of the datadbspecific.dll. I then used a static method in a class to create a new DataAccessAdapter from the datadbspecific.dll using reflection. The idea was not to switch between, but to allow the app to work with multiple data stores.

There was no UI code involved with the exception of loading the special file that pointed to the database.

This sounds like what you are looking for doesnt it?

I've attached the "hard" part. I also created a configuration class that was editable via PropertyGrid control so they could switch between db's during run time.

Let me know if this is what you are looking for...

I'm giving it a shot with "reading between the lines" for you config class. It sounds and looks like it might work.

Thank you very much for sharing and I'll keep the thread (you) informed of the results...

Norman

It does work. I actually added support yesterday for encrypted connection strings using symmetric encryption. It works like a dandy! I also made it a little faster by eliminating a couple of things that were re-instantiated every time. It should work faster now as well.

Seth wrote:

It does work. I actually added support yesterday for encrypted connection strings using symmetric encryption. It works like a dandy! I also made it a little faster by eliminating a couple of things that were re-instantiated every time. It should work faster now as well.

Seth - I meant for what I'm trying to do What is the ObjectType used in the CreateInstance and MethodInfo if I could bother you for that information.

Thanks, Norman

normanlc wrote:

Seth wrote:

It does work. I actually added support yesterday for encrypted connection strings using symmetric encryption. It works like a dandy! I also made it a little faster by eliminating a couple of things that were re-instantiated every time. It should work faster now as well.

Seth - I meant for what I'm trying to do What is the ObjectType used in the CreateInstance and MethodInfo if I could bother you for that information.

Thanks, Norman

ObjectType is the actual name of the class that uses the IDataAccessAdapter interface. LLBLGen always calls it DataAccessAdapter. The reason I did this was to make sure the user put the correct dll into the configuration file. If you slap the object into a propertygrid it will actually look for the proper object when you select the correct DataDBSpecific.dll. Maybe I should write something up on it with some screen shots. Let me know if this would be useful.

Oh, and the best part was I added a custom type of provider called and Enterprise Provider which could be used to create a wcf or any other type of dynamic instantiation.

Seth wrote:

normanlc wrote:

Seth wrote:

It does work. I actually added support yesterday for encrypted connection strings using symmetric encryption. It works like a dandy! I also made it a little faster by eliminating a couple of things that were re-instantiated every time. It should work faster now as well.

Seth - I meant for what I'm trying to do What is the ObjectType used in the CreateInstance and MethodInfo if I could bother you for that information.

Thanks, Norman

ObjectType is the actual name of the class that uses the IDataAccessAdapter interface. LLBLGen always calls it DataAccessAdapter. The reason I did this was to make sure the user put the correct dll into the configuration file. If you slap the object into a propertygrid it will actually look for the proper object when you select the correct DataDBSpecific.dll. Maybe I should write something up on it with some screen shots. Let me know if this would be useful.

Oh, and the best part was I added a custom type of provider called and Enterprise Provider which could be used to create a wcf or any other type of dynamic instantiation.

Seth:

I would find it very useful and greatly appreciate it. It's truly nice to see enthusiasm!

Norman

Walaa wrote:

The idea is simply to create 2 LLBLGen Projects, one targeting Access and the other targeting SQL Server. (The schema should be identical) Please check this thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=7430

Then you should use the Adpater model to generate your code. DataBase Generic project should be the same in both projects. So now you should build, One Database Generic dll, and 2 Database specific dlls.

Use the Database Generic dll through out your application, and at runtime or configure time, you should load the relevant DBSpecific dll.

Please check the following thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=12337

Since I haven't heard back from Seth I'm working my way through a solution...

In attempting to compile the DLL which was generated from LLBLGenPro v2.6 I disabled the SD.Tasks.Adapter.DatabaseSpecific in the Run Queue on the Task queue to execute tab of the "Generate..." menu option...

I receive 15 errors when I attempt to compile the Generic DLL...

The type or namespace name 'DynamicRelationBase' could not be found... File: DynamicReleationship.cs

The type or namespace name 'ElementCreatorBase' could not be found... File: EntityFactories.cs

The type or namespace name 'IElementCreator2' could not be found... File EntityFactories.cs

8 of these: Lines: 30, 42, 42, 53, 1468, 1479, 1479, 1491 The type or namespace name 'DerivedTableDefinition' could not be found... File DynamicRelation.cs and EntityFactories.cs

4 of these: Lines: 1468, 1479, 1491, 1504 The type or namespace name 'IDynamicRelation' could not be found... File EntityFactories.cs

Should I be generating the code with a Database Specific and then only use the Generic portion?

Norman

Mmm.. I tested that and everything is OK to me. To be sure, please

1. Update to the latest build of LLBLGen v2.6
2. Generate to an empty folder and see if the compilation errors persist.

daelmo wrote:

Mmm.. I tested that and everything is OK to me. To be sure, please

1. Update to the latest build of LLBLGen v2.6
2. Generate to an empty folder and see if the compilation errors persist.

The build succeeded after updating v2.6

Thank you, Norman

I am sorry for not getting a post up! I have been extremely busy. The interesting thing to note is that I have to do some things in order to get it to work faster in the ASP.NET setting since I do not want the xml file with the configuration to be re-parsed every time a IDataAccessAdapter object is needed. Since I am using the singleton pattern, this is not a problem in the winforms arena. I was thinking of some kind of dependency injection solution for persisting the xml data in the asp.net session.

In an effort to get you something, I installed trac on top of an svn repository so you can look at the code.

http://strivea.svnrepository.com/namespace/trac.cgi/browser/trunk/Strivea.DataFactory

Let me know if you have any questions. There is also a winForms utility for creating the actual xml config file. I bet there are smarter ways to do this; I would love for some input.

Seth wrote:

I am sorry for not getting a post up! I have been extremely busy. The interesting thing to note is that I have to do some things in order to get it to work faster in the ASP.NET setting since I do not want the xml file with the configuration to be re-parsed every time a IDataAccessAdapter object is needed. Since I am using the singleton pattern, this is not a problem in the winforms arena. I was thinking of some kind of dependency injection solution for persisting the xml data in the asp.net session.

In an effort to get you something, I installed trac on top of an svn repository so you can look at the code.

http://strivea.svnrepository.com/namespace/trac.cgi/browser/trunk/Strivea.DataFactory

Let me know if you have any questions. There is also a winForms utility for creating the actual xml config file. I bet there are smarter ways to do this; I would love for some input.

Thank you Seth... I will certainly provide feedback.

Norman

I think there is a better way using dependency injection. Let me think about it a little more.

Seth:

The assembly appears to load fine, but when the following line of code is executed:

adapter = (SD.LLBLGen.Pro.ORMSupportClasses.IDataAccessAdapter)assembly.CreateInstance(dac.ObjectType);

adapter is null?

dac.ObjectType is defined as: "DataAccessAdapter"

the adapter is: SD.LLBLGen.Pro.ORMSupportClasses.IDataAccessAdapter adapter = null;

just above the try block (code as you have it)...

What would cause that?

Thanks, Norman

Here are some things you need to have in the folder where this is executed (these are dependencies in the DataDBSpecific.dll):

The ORM support dll specific to the provider you are using. (required by datadbspecific.dll) The actual DataDBSpecific dll.

Drop these into the directory where the DataFactory dll makes the call. This is off the top of my head since I dont have the stuff in front of me.

Also, make sure the ObjectType variable in the Configuration has the FULL path to the DataAccessAdapter class: YourNameSpace.SubNameSpace.DataAccessAdapter

Let me know if this works!

I have been using that dll for years now without much problem.

Seth wrote:

Here are some things you need to have in the folder where this is executed (these are dependencies in the DataDBSpecific.dll):

The ORM support dll specific to the provider you are using. (required by datadbspecific.dll) The actual DataDBSpecific dll.

Drop these into the directory where the DataFactory dll makes the call. This is off the top of my head since I dont have the stuff in front of me.

Also, make sure the ObjectType variable in the Configuration has the FULL path to the DataAccessAdapter class: YourNameSpace.SubNameSpace.DataAccessAdapter

Let me know if this works!

I have been using that dll for years now without much problem.

Thank you Seth, it was a namespace issue.

Norman

I'm glad it worked! In a couple of weeks, I'm going to try to use IoC to make a more elegant solution. I'll let you know.

Seth wrote:

I'm glad it worked! In a couple of weeks, I'm going to try to use IoC to make a more elegant solution. I'll let you know.

I look forward to hearing from you. I'm still working through my solution and I will provide the feedback as stated earlier.

Norman

Seth:

I've downloaded and played with the "new" method via the link you provided...

Looks really good! Thank you ever so much for the assist, it was exactly what I was looking for to address my issues!

Norman

Thats good to hear! I've since opted for using IoC using an IAdapter interface that has a Create( ) method that returns the appropriate adapter. It works too...

Seth wrote:

Thats good to hear! I've since opted for using IoC using an IAdapter interface that has a Create( ) method that returns the appropriate adapter. It works too...

Yesterday afternoon and this morning I've trying working with an MsSqlServer database and keep getting a NULL for the adapter in DataAccessAdapterFactory; however, the catch block is not "catching" any exception however the adapter is null as stated. _assembly.CreateInstance(_config.ObjectType) has the right string and in checking the DLL with .NET Reflector all looks okay, any clues why that is happening?

Are the new files on that same link?

Thanks again!

Norman