Beginning DNN 5.1.0 and higher, they added an extra parameter column in the Schedule table called "CreatedByUserID".  However, the Interactive User Import version 2.0 install zip file (01.00.00.SqlDataProvider) is still using the AddSchedule that is compatible with previous versions of DNN.

For DNN 5.1.0 and higher, you will need to edit the "01.00.00.SqlDataProvider" file in the .zip install and change the text from:

-- ADD DNN SCHEDULER ITEM
execute {objectQualifier}AddSchedule 'DataSprings.DNN.Modules.UserImport.UserImportProcess,

DataSprings.DNN.Modules.UserImport',60,'m',60,'m',250,'',0,1,'DataSprings_UserImport', NULL

to:

-- ADD DNN SCHEDULER ITEM
execute {objectQualifier}AddSchedule 'DataSprings.DNN.Modules.UserImport.UserImportProcess,

DataSprings.DNN.Modules.UserImport',60,'m',60,'m',250,'',0,1,'DataSprings_UserImport', NULL,1

 

Note: the 1 at the end is the userID for the parameter "CreatedbyUserID" parameter.  The number 1 is usually for Host.

Another option is to go into Host / Schedule afterwards and add the Interactive User Import manually.  If so, supply the following info:

Full Class Name and Assembly: DataSprings.DNN.Modules.UserImport.UserImportProcess,
DataSprings.DNN.Modules.UserImport

Object Dependencies: DataSprings_UserImport

The rest of the choices is up to you. -- David

 

Does this work for the 1.50 version with DNN 5.0.1 as well? Do I have to purchase 2.0 seperately? It doesn't appear available in my snowcovered account.

Thanks for any info!

A

Hi Andi, I don't know about version 5.0.1. You can go to host / sql and type in:

select * from schedule

and see if you see a column for "CreatedByUserID". If it's there, then you will need to follow the instruction above. Yes, the same process would need to be done with IUI 1.50. As for getting 2.0, it's a new release so you may consider upgrading to it. Please check out standard Upgrade Policy at: http://www.datasprings.com/Support/...fault.aspx

-- David

It looks like DNN has now added another new parameter to the AddSchedule stored procedure. As of version 5.2.3 the last two parameters to that procedure are @CreatedByUserID and @FriendlyName.

So, the line in 01.00.00.SqlDataProvider should now be:

execute {objectQualifier}AddSchedule 'DataSprings.DNN.Modules.UserImport.UserImportProcess, DataSprings.DNN.Modules.UserImport',45,'m',60,'m',250,'',0,1,'DataSprings_UserImport', NULL, 1, 'DataSprings UserImport'

 

It's a bit disappointing that this problem with Interactive User Import hasn't been fixed. If the module doesn't yet work with recent versions of DNN, you should tell people this before they pay for it.

 

HI, all our modules work fine with the latest versions of DNN. The problem is only when a module requires the service of the Scheduler. We always use the "AddSchedule" stored procedure which is a DNN stored procedure. However, by the time we release our product (let's say IUI 2.0) and DNN was still in version 5.0, then the "AddSchedule" will work fine because DNN 5.0 didn't have the extra column @CreateByUserID. So anyone using older versions of DNN, the install will add the scheduler but if they upgrade their DNN and install, it will error out. By the time we fix the install to support DNN 5.1 for example, DNN 5.2 may come out and they add another column called @FriendlyName and the install will error out for this version.

For the moment, we are chasing our tails trying to keep up with all the versions of DNN out there and even in our test environment, we may not have the latest DNN version and not be aware of certain changes. But this only effects the "AddSchedule" routine since we are using their stored procedure.

But the module itself still works for higher DNN versions onward. This usually only effects modules that uses a scheduler routine and is using the DNN stored procedure which they sometimes change going forward. But when a customer encounters this, we do help out and post on the forum how to add the schedule manually or run the SQL "AddSchedule" routine with the updated column item.

Going forward, we are considering using code within the VB.NET itself as opposed to using the DNN "AddSchedule" routine to prevent this trouble from happening. But this only started happening in DNN 5.0 and higher when they started adding new column fields. -- David

David,

I know that you are trying your best to keep up with a moving target (the changing DNN DB API), but nonetheless your statements above are in my opinion misleading.

All our modules work fine with the latest versions of DNN. The problem is only when a module requires the service of the Scheduler.

What you don't say is that this particular module (Interactive User Import) doesn't do anything unless the Scheduler is correctly configured. The install process that comes with the module doesn't install the scheduler correctly on the latest DNN (5.2.3). If you follow all of the install instructions that come with the module's documentation, you would have no idea that anything had gone wrong, until mysteriously the scheduled process doesn't run. There are several posts in this forum by people who have had this problem, or a variant of it -- three that I have found with a cursory search. People are legitimately confused by a problem which isn't addressed in the product documentation.

As far as I can see this problem will affect every user who installs a new (v5 or later) install of DNN, until you fix the install script. If you would come clean and simply say, "yes, I know it's a problem; we're working on it", instead of "all our modules work fine", you would seem a good deal more credible.

Regards,
Oliver