[Please Ignore] Connection string not set when I resolve IDbConnectionFactory

Hi. I am trying to resolve an Idbconnection from within a quartz job, but the connstring is always empty and so crashes when trying to open a db connection. What am I misunderstanding about the dbconnfactory that means the connstring is lost when IDbConnectinFactory is being resolved?

I am using @Mac 's Quartz job tool, specifically I try to resolve a service from within a Quartz job and/or create a dbconnection to query the db directly in my job.

In all my API logic (e.g. the Service endpoints), if i use my Idbconnectionfactory registration (which i believe is a singleton?), things work great.

container.Register<IDbConnectionFactory>(new OrmLiteConnectionFactory(connectionString, SqlServer2012OrmLiteDialectProvider.Instance));

But while I can resolve a service (and the idbconnetionfactory) from within a quartz job, i cannot USE the factory OR use the service (which in turn uses db connectivity), because of this missing connstring?


public class HarvestMsEquityListingGenericInfoJob : IJob
           // autoinjected
	public HarvestMsEquityListingGeneralInfoEndpoint myService { get; set; }

       // autoinjected
	public IDbConnectionFactory myConnFact { get; set; }
	public Task Execute(IJobExecutionContext context)
		// both myService and myConnFact are resolved and
                // injected by Funq - so far so good
		// BUT ... next line fails, dbconnstring not set ???
		using (var db = myConnFact.OpenDbConnection())
			// try to get stuff from db, but can't 

                // I also tried resolving a service or an idbconnectionfactory 
                // from the HostContext directly, but same issue, so i think 
                // problem is my Funq, not Mac's library?
                // same issue on next line, dbconnstring is emtpy and connection 
                // fails on use of harvestService.Db
                // using (var harvestService = HostContext.TryResolve<HarvestMsEquityListingGeneralInfoEndpoint>())

@Mac’s project, for reference (he doesn’t do any db access, but Mac if you have had this working before, I would appreciate your comments as well?)


Never mind… I am an idiot. It seems I am unable to deleted this forum ticket, but my apologies - I had a typeo that I have been overlooking between a test library and my main library, for the last two hours.


@daleholborow dependency injection isn’t something I tested all that much but it does just register the Jobs with the AppHost’s Funq container and then resolve them when creating an instance, so it should pretty much ‘just work’

Glad you got it sorted. We’ve all had those adventures before! :smile:

1 Like