I have a Notes application where we have a Live version and Development version. Something strange is occurring on the Live version and I wish to export the affected documents from Live to Development with the aim of using these for a work around. Is there an easy way to do this?
Use copy/paste:
select the documents in question in the live version
choose Edit - Copy
go to the development version
choose Edit - Paste
Related
Is there any way to prevent any changes (i.e., lock or hide) to the calculated columns or scripts in a Spotfire file (.dxp).
We are trying to deploy a template / file we built in Spotfire and would like our team to use it as is and prevent any accidental changes while we continue to work on updates etc...
Any help would be greatly appreciated!
There are a couple of ways you can go about this. For scripting you can remove the scripting licenses from the users of the dxp. But this wouldn't prevent the calculated column changes. The best method, in my opinion, is duplication and versioning.
Deploy your live template to a public folder and then keep a backup in a folder where only you have access. Then, edit another copy of the template with a version control number like Template2_2.dxp. When you are ready to deploy it, just overwrite the live version. You will already have a back up of the live version, so now you just need to backup your newest one.
It's the most basic but easy method and ensures you don't leave room for mistakes or over limit your users by removing licenses.
In a rather complex project the entire project team is encountering more and more problems regarding designer, like frequent crashes, exceeding of memory limits and- most annoying - problems with outdated project data:
quite often we observe that two different designer clients are showing different versions of project data (see below for a rough description of the environment).
A simple example: an hour ago a co-worker asked me to open and test a new Xpage she had created 15 minutes ago in her Designer. In my Designer client however the new Xpage was not present yet. right-clicking my application and hitting "refresh" brought up the new Xpage.
The problem hits the ceiling with design elements that we both are working on in turns (as in "are you currently working on xpage XXX? I'd like to add..."). So with this syncing delay the problem is obvious: If I foirget to manually sync my project before adding stuff I will overwrite the co-workers' codings.
We never had this problem before, although I have to admit that we never had to work in a team on such a massive project.
Here's the setup:
all designer clients are 9.0.1 FP6
everyone is working on the same project stored on the same server
everyone is working on the same network withion the same building, just door-to-door
Is there something we could do or check to improve this situation?
Lothar, you have stated three problems at once. I'll try dissect them.
Frequent crashes:
We experienced many, many crashes in our daily work after upgrading to Windows 10. I know it sounds silly, but one way it worked for us and successfully mitigated those crashes was installing IBM Designer into C:\IBM\Notes, instead of C:\Program Files\IBM\Notes.
Granting 'Full Access' to 'All Users' over that folder was also necessary.
Exceeding of memory limits: As jtomas correctly pointed out, default memory settings are not enough for heavy xpages development in Domino Designer. I would suggest going to vmarg.Xmx=-Xmx1024m.
Problems with outdated project data: I think there is no workaround for this problem because there is no problem. Domino Designer 9 is a Eclipse based software, and works like so.
Think about it: When working in Java projects, developers download (checkout) source files from a Source Control System (SVN, Git, etc) and work them locally. Whenever a developer modifies or create a file, another developer can see it only if:
a) The modified/new file has been uploaded (commit) to Source Control Repository; and
b) Other developers have synchronized (refresh) their local projects with the repository.
See, that's how Java development works and that's the way we should do it too. Upon opening a NSF file, Domino Designer breaks it down into many files, just like a Java project. Once locally saved into the Java Virtual File System, those files get updates only when you refresh the project. Silly, but it is what it is.
My recipe to a well succeeded Domino development team include:
1) Design locking: All developers must explicitly lock elements they will work on. We don't rely on implicit locks.
2) Communications: All members of the team must be immediately notified whenever a developer has made major updates to the project.
3) Source Control: Despite its pitfalls, we rely heavily on SVN as code repository. It's far from perfect, and merges don't work properly, but it's better than no control.
Hope it helps.
I'm not sure this will fix your syncing issue but I have found modifying the following 3 lines in your local Notes\framework\rcp\deploy\jvm.properties file to help with Designer performance when developing in XPages especially with large projects:
vmarg.Xmx=-Xmx512m
vmarg.Xms=-Xms48m
vmarg.Xmca=-Xmca512k
These are the memory limits I use. You can increase the limits just make sure they are a multiple of 4. You have to restart Notes & Designer for changes to take effect.
This is my first time ever working with Lotus Notes, where the client want to move its database to mysql.
I have spent a week to read on Lotus Notes but going nowhere. When I search for some tool to migrate database, it does not support version 5.
It is a better idea to upgrade to latest version and than migrate...please advice...
Yes, you can update to latest IBM Notes/Domino version and database will still run without any change. That is one of the cool things about Notes...
We are using WSS 3.0 at work to manage design documents for our systems. We work in a parallel environment which means we usually have a production copy of a document (e.g Doc A) plus also two or more versions of that document that will be worked on by independent project teams (Doc A (proj 1) & Doc A (proj 2)), we have in the past achieved this by keeping the documents in seperate site collections, however this is very messy and over time has become extremely hard to keep track of the latest versions.
What I am trying to achieve is to store all versions of Doc A in the same document library keeping the name the same but distinguish the different versions of the document using meta-data fields so that users will be able to view the production version of the document while proj 1 and proj 2 can work on their documents seperately. Each individual version of the document must also be searchable using the WSS search.
E.g Name Project Name
Doc A Production
Doc A Proj 1
Doc A Proj 2
I have thought about simply using version control in the library to maintain the different versions of the document and allow the users to simply go to version history to choose which document they want to view or work on. The issue with this approach is that I can not get the seperate version of the document to show up in the search results.
I am stuck with WSS 3.0 for at least another 12 months, so my solution has to be WSS 3.0 based.
Has anyone had experience trying to implement something similar and if so what was the solution that you used? I can't imagine that I am the only one trying to cater for a paraelle development environment.
Short Answer: Renaming Document is the solution (Post-fixing something to make distinct document name).
Long Answer: I got chance to migrate huge document base from oracle portal to MOSS 2007 and I spent time to find out the solution. Finally I ended up post-fixing versions manually/programmatically in the event handler.
Regards,
Azher
How do you handle improvements and added functionality to your existing SharePoint code?
Did you deploy your original code as a feature?
Do you create a new feature_V2 and deactivate the original?
What processes have you found that led to problems in the future?
I am specifically interested about WebParts, EventHandlers, and WorkFlows.
From what I can find, MS did not leave a "Best Practices" around updating existing code. (Actually, I'm not sure they left a "Practice" much less a "Best Practices")
You can see other questions around this topic:
how-to-upgrade-a-long-running-sharepoint-workflow-already-in-production
how-to-update-spitemeventreceiver-assembly-version-for-a-list-in-sharepoint
should-i-keep-solutions-and-features-in-a-1-1-ratio
What is your method?
I understand this question may be subjective, but I feel there is a large information gap surrounding this area of SharePoint development.
Thank you,
Keith
We always deploy custom code as features and solutions. When it is time to upgrade the existing code, all you have to do is stsadm -upgradesolution and everything works very nicely. I do not like the idea of having feature_v2 type features around...it makes it extremely difficult to keep track of the current version. I think you should only have one version of each feature in your production environment.
Leave the version control to your source control system.
I'm working at a shop that does a lot of SharePoint development. You want to deploy by feature with a solution package. You can easily upgrade your features as you go along and you will need to upgrade the solution package. This solution package can be created from a TFS Build server with WSPBuilder. As you along, the only thing left is to upgrade the solution and "Force" reactivate your feature to have the new feature of the feature.
Don't forget to do an IIS reset for any new code deployment that is done through the GAC. If you put anything inside like sitemaps and resources inside your 12, you will want to do a stsadm -o copyappbincontent.
If you deploy features that contain application files, you want to unload your application on ALL servers of the farm. It can easily be done by putting an App_Offline.htm at the root of every application on every machine.
When completed, remove App_Offline.htm (or rename it) and you are done. Your site is back online.