As the developers of Open Journal Systems, Open Conference Systems, Open Harvester Systems, and Open Monograph Press, the PKP team are experts in helping journal managers and conference organizers make the most of their online publishing projects. PKP Publishing Services offers support for:

As a customer of PKP Publishing Services, you will not only receive direct, personalized support from the PKP Development Team, but will be contributing to the ongoing development of the PKP applications. All funds raised by PKP Publishing Services go directly toward enhancing our free, open source software. For more information, please contact us.

1. Search the forum. You can do this from the Advanced Search Page or from our Google Custom Search, which will search the entire PKP site. If you are encountering an error, we especially recommend searching the forum for said error.

2. Check the FAQ to see if your question or error has already been resolved. Please note that this FAQ is OJS-centric, but most issues are applicable to both platforms.

3. Post a question, but please, only after trying the above two solutions. If it's a workflow or usability question you should probably post to the OCS Conference Support and Discussion subforum; if you have a development question, try the OCS Development subforum.

I spent last night importing 1000+ users into my new OCS site - 50 users at a time!!! Very painful. The site is running OCS 2.3.5 and the users were exported - using the same plugin - from a 2.3.3 site. My exact problem is described in this OJS forum post:

It seemed odd to me that this guy's import was cutting out after exactly 10 records and mine was stopping after 50. I suspect that this error might have something to do with the # of items displayed on a page:

; Number of items to display per page; overridable on a per-conference basisitems_per_page = 25

I really only suspected this because they were both such round numbers and I had this variable set to 50. Changing this variable didn't help, however.

Even if this is probably not the case, I'm hoping that the developers can offer a solution so that no one else will have to endure what Charles and I went through in order to get users imported into our new sites.

Ok, so I'm setting up another conference and I find myself back at this same unresolved thread. Tonight I have to import about 1200 users. After first having to track down a bug on the export end of things, now I'm faced - again - with a bug while importing.

Are you seeing the same error message that was reported on the other thread ("DB error:column 'first_name' cannot be null")? If so, have you tried validating your XML before importing it?I'm not sure yet, but I suspect that items_per_page is a red herring (or if not, that you're experiencing a different problem than the fellow on the other thread).

Yes, still get the same problem of only being able to import 50 records at a time.

I ended up doing it from the command line for this conference (based on Jason's suggestion above). That turned out to also be painful and a long, drawn out procedure.

I didn't validate my XML, but, considering it was generated by the OCS export user plugin, I didn't think that this would be necessary. Also, the fact that I can reliably import 50 records at a time seems to indicate that that XML is just fine.

I will provided details of the problem with the command line import and the solution/hack I came up with to get past it.

This is because, in order to lookup the scheduled conference, the function getSchedConfByPath (in classes/schedConf/SchedConfDAO.inc.php) needed to know the conferenceId. It looks like it should be able to manage without it, but this was not the case. I assume this was because it was being called from the command line.

So, to get it to work, I temporarily hacked line 214 in tools/importExport.php by supplying the conferenceId=1 to getSchedConfByPath.

I can't duplicate this error with OCS 2.3.5, the current stable branch, or the current unstable branch. I've tested with 60-user imports and all the users come in without trouble.

Without being able to duplicate the error it's difficult to help debug, but my suspicion is that you're trying to import users that don't have a first name. Technically OCS requires a first name to be specified. (There are work-arounds that can be used to trick OCS into accepting users without first names, and if your source conference has used those, it may be that it's generating a user export without first names and the target conference is rejecting it.)

This doesn't explain why importing users in smaller batches works while performing the whole import doesn't. Is it possible that the process you used somehow avoided importing a record without a first name specified? Did you try the entire import in one file when using the command-line based import?

Unfortunately I'm still not able to duplicate this problem. I started with a fresh OCS 2.3.5 installation, created a new conference and scheduled conference, applied the patch for bug #8082, and tried first the command-line import:

Next, I restored my installation to its fresh state, and tried the same process via a web import. Importing many users that way results in some very long pages, but again, everything behaved as expected.

There are still many variables at play here -- your PHP version (mine is 5.3.3), your MySQL version (mine is 5.1.50), the upgrade and maintenance history of your OCS install, etc. If any of this process differs substantially from what you've been doing, please let me know.

If you're able to duplicate the error message, try turning on the "debug" option in config.inc.php just before you do it. This will result in any requests to OCS also including database statements, which may be relevant. (Note that you'll only want to turn this on briefly.)