How to create multiple user's on Domino Server without actually configuring physicaly on it? - lotus-domino

I have made an application which is reading domino server mailboxes and saving it on another location.
I am able to read and access all mailboxes.
Now to test product i want to create about 100 to 200 user's.
I am able to create user's but but in order to add mails,calendar e.t.c.
I need to physically configure user on machine then creating all items.
Is there any other alternative? Which allow me to add mails or other data into these nsf files?

Take a look at the RegisterNewUser in NotesRegistration class
Here is the documentation --> http://www-12.lotus.com/ldd/doc/domino_notes/7.0/help7_designer.nsf/f4b82fbb75e942a6852566ac0037f284/7604e322d563f2618525704a0040ee80?OpenDocument

Related

Access multiple system using single user credential in orangehrm

how to connect more than one system authentication using single credential in orangehrm?
I have add one user in system1 and that user will be automatic added into system2 using orangehrm. How I do that? Please Reply me if any one know answer about it.
I assume you are referring to two OrangeHRM systems. If you can sync the ohrm_user table in both systems, you can achieve this.
You can write an external script/app which syncs the two tables periodically (eg: every 5 minutes).

MS- Acess database interface update from local

I am extremely new to Ms-Access. I have a central back end access database in server computer. And all the users have the front end user interface installed on their system.
Now, whenever I make any changes to the interface in my local, i need to re-install the updated interface on each of their system. Is their any way that i can do so that i will make the changes only on my local and it will be automatically reflected on all the users' systems.
Thank you.
Ok there are a couple of options that you can do to either fully or paritally automate this process.
Partial Automation
If you don't have a lot of users and you don't want to do a great deal of coding you can write a simple batchfile or vbs file which you set up on the users desktop as an icon. Batch file code would show the following type of information.
#Echo Off
REM Copy your file from server location to local user machine
xcopy "F:\ServerDirectory\databasename.mdb" "C:\ClientDirectory\databasename.mdb" /E /Y /R
Set this up on the users machine as an icon and whenever you want them to update their front end ask them to double click the icon. This will overwrite their client with whatever you place in the location on the server. It is advisable to create all table links to the database back end having UNC paths as well.
I have used this successfully for various applications - I make changes to the front end place in appropriate location on the server and then do a quick e-mail to people just to ask them to double click the bat file icon.
Full Automation
Programmatically set version control up using visual basic so the client checks version number of the client against a server number and if the client is not the latest will download a new version.
This is more involved and full instructions are available here.
Front End Auto Update
When you deploy an MS Access solutions like this, you need to decide whether to share the client MDB file between all users, or distribute copies to each user. It sounds like you have taken the second option. Each choice has merits and disadvantages. If you stay with the current approach, you might look at a scripting option to deploy updated client MDB files between users.

how to store Settings per customer (not per application and not per user) in ClickOnce-Excel-Addin

I am working on a VSTO-Excel-Addin (VB.NET) that we are about to sell to different companies.
The addin will (hopefully) be used by a couple of users of each customer. We are using ClickOnce for a web-based deployment.
The addin provides some default-settings - that is no problem with the app.config. User-specific Settings are also working fine with ClickOnce.
However what makes quite some headache is how to store settings per customer. Database-connectionstrings for example cannot be stored on the application-level but it would also be painfull for all users to change the Connection-string manually. What I would imagine is another layer (per Company) where this sort of Setting can be stored.
One alternative would be to create one VSTO-Project per customer but this would bring a lot of disadvantages since we are updating the addin quite regularly.
I would be happy about any ideas!
Regards,
Julian
I would show Excel's built in connection properties dialog and let each client configure this themselves.
You really shouldn't be distributing connection strings for all your clients as part of a shared package. It'll be a maintenance nightmare.
http://office.microsoft.com/en-nz/excel-help/connection-properties-HA010175443.aspx
What about storing the settings as custom properties in Book.xltx and copy it to
C:\Users\username\AppData\Roaming\Microsoft\Excel\XLSTART
This is how you can programatically read and create Custom Properties in Excel.
When a new workbook is created then all the properties from Book.xltx will be available for New Workbook as well. But this solution may not work if the existing workbooks are opened so yo might have to explicitly add these properties when any existing workbooks are opened using the above solution.
Ok, I think I understand the problem. :)
How about storing all the settings in an offsite database that you maintain and using a webservice to allow the settings to be read and set and giving each client a unique license number that would allow them to access this webservice.
That way the individual users would only need a license number to set it up.

Use VBA ( ADODB) in MSAccess to append data from remote DB to a local table with out locking records in the remote DB

What I'm trying to do is seperate my existing MS Access application into a front-end (which will run locally on a user's machine) and backend (which will be hosted on a networked file server) and allow users to choose between "read-only" and "write" modes. The idea is that only one user can use the "write" mode at a time, thus preventing the same piece of inventory being allocated to mutliple customers. My problem is that the application currently handles concurrency by requiring users to open a .bat file which only allows them to enter application if a .ldb file does not already exist (there is no read-only mode currently), so I need to prevent users accessing the production data in "read-only" mode from creating a .ldb file and unessarily blocking out other users.
The biggest challenge to implemnting this is that users must have write access to the temporary tables in the MS Access (.mdb) file installed locally. I have tried to implement this using a linked table, but I'm not sure how I can control when records become locked using linked tables (which creates a .ldb file).
You could change the sharing setting back to Exclusive Mode. Then only one person can access the file at a time. Check out this link and the other sharing options you have.
http://office.microsoft.com/en-us/access-help/set-options-for-a-shared-access-database-mdb-HP005188297.aspx
Side note: Yikes. Using Access in a shared network environment is not fun. I hope nothing important/time sensitive/secure is in this file. The .ldb file not being deleted and blocking other users is something that I use to see happen regularly in this situation. I believe splitting the Access file into a front-end and back-end like you've done is the first step. Then using linked tables to a SQL Server database can help resolve these issues. But if you're going to this level of effort you may want to consider dumping Access and get a COTS product or create a new application.
Depending on which version of Access you are using, theres alot of flexibility in the UI developement. In other words, this sounds more like an "interface" issue as apposed to a "database" issue. Given everybody is able write to a table, you should be able to check in somewhat real time (performance can be an issue with larger datasets), whether a particular has been added to inventory or not.
They I handled this problem is have two tables, an incomming and outgoing log, and set up a query that did the math against the inventory list on the amount of products. And like a general ledger, select set amount of time to "close the log" (monthly, quarterly) so that the query is not taking into account stuff that happened two years ago.
If you need more help with Access related stuff, Access Monster is a good forum site that deal with nothing but access.
My problem is that the application currently handles concurrency by requiring users to open a .bat file which only allows them to enter application if a .ldb file does not already exist (there is no read-only mode currently), so I need to prevent users accessing the production data in "read-only" mode from creating a .ldb file and unessarily blocking out other users.
--> If every user has his own copy of the front-end on his own machine, you'd have to check the .ldb file of the back-end.
I guess it would be easier to give everyone write access to the backend and manage the actual writing programmatically with a "locked by User X" field in the backend:
You said:
preventing the same piece of inventory being allocated to mutliple customers
If this is the only reason for putting all users but one in read-only mode, you could put a "locked by User X" field on the inventory table. If someone starts to modify (or even opens) a piece of inventory, update the record with his user name, and delete the user name again when he's done.
If another user tries to open the same piece of inventory as well, the name of the first user will already be in the "locked by User X" field, so you can put the second user in read-only mode.
If the inventory pieces are not the only problem and all the other users really are not allowed to change anything as soon as someone else already is editing, you can create a new table with only one column and one row and use this as the "locked by User X" field. As soon as there is a user name inside, you can put everyone else in readonly mode.
No matter how you do it, you will have to provide some kind of admin menu, so if someone's front-end crashes while editing, someone else needs to be able to unlock this user's locked data (=delete his username from the "locked by User X" field).

Synchronize 2 SharePoint Libraries on Different Servers

I need to copy or synchronize 2 libraries between 2 different servers. Here are more details:
1- I have an InfoPath form that is submitted to a document library, Lib #1.
2- The InfoPath form is published as a content type and Lib #1 is configured to deal with this content type.
3- The users will have the ability to add new items to Lib #1.
4- At the end of each day, or may be every hour or so, I need to copy the newly created items or sync Lib #1 with another library on a different server.
5- The content type will be available in both servers.
I am new to SharePoint so I appreciate if you can show me some hints on how to achieve that.
Clarification
I don't know which route to take, I am thinking of utilizing any of these (if possible):
1- Replicating Database: Use replication to copy data from one SharePoint database to the other
2- File System: I am not sure if the forms are saved in file system but if they are, I could copy the forms from one server to another.
3- Programatically: I am reading about SharePoint server events. I can program against the List Item Added event and try to copy the item from one server to anther.
4- Built in: May be there is a built in tool that I am not aware of that can help me copy items.
Why do you want to do that ? If the target is entirely different server, forms won't open from there unless you relink the documents and you have same form template deployed on that server.
To do this job, you have two options:
Realtime - Use ItemAdded event handler, to copy the item to target as soon as it is created.
Timer Job - You can create a timer job which will run as per some schedule and copy the items from one library to other.
Reject the DB and file system approach. Accessing DB directly is not supported. And these are not stored on filesystems. SharePoint API is only way. You can use either in Event handler or timer job.