I have an sapui5 code on HANA studio and would like to know how I can programatically tell if I'm in Dev, test or Prod environment. Is there a way to do this?
You can use the system view M_DATABASE as documented here.
In column USAGE you can find whether the system is used for production, test, development, demo, ...
SAP HANA Studio uses this information to set the UI colour differently for production systems and to provide additional confirmation dialogues when changing data.
Related
I am using Aqua Data Studio for my internship project. But the evaluation period has finished and now I cannot use it anymore. Please can you suggest me an IDE that is similar to Aqua Data Studio? Some software that is not commercial.
I would like to register some Oracle databases servers and PostreSQL.
Can I use MySQL Workbench? Would that be possible with it? Is there any difference?
Copy the technical information available in the Aqua Data Studio menu Help -> Support Information and email the above information to the support email address, architect#aquafold.com and support might extend your evaluation.
You could use google data studio, which is free.
Does anyone know how you version / source control changes in Reddot Cms (OpenText). Also is there any best practice advice for release management of changes from one Reddot environment to another Reddot instance. Any help or advice would be greatly appreciated.
There is best-practice, but as you have probably realised, there aren't too many practitioners of RedDot these days. In case you should come back to this thread (or for someone else's benefit) Versioning is built into the Template Manager, but has to be enabled. There's no Source Control integration last time I checked, but we developed a prototype system that allows for the creation of templates in Visual Studio. The project to complete that has since died due to lack of commercial support, but some of the ideas may be useful for you if you want it.
I split up the answer in two parts: Versioning and migration between stages.
Versioning can only be done with the template history or via an external service that grabs the templates on a regular basis or triggered manually. At least for the Management Server there is no built-in service for a "real" versioning or release of more than just single templates/content classes or even including pages.
There are 3 ways of moving changes from dev to test or prod I have seen often:
Two templates: Using two templates on one server, on called "Development" and the other one "Production". All new development is done on the "Development" template and moved to the other template as soon as finished. If elements are different between those templates they need to be duplicated. This is typically on small installations without staging areas. Nowadays, you will find only very few of those.
Partial tree export: Development is done on a dev server and the changes are exported as partial tree. There is a special area in the project tree where pages are created which templates shall be moved over. These are exported including the templates and imported on the target server to override the existing ones.
Tool support: There are external tools for moving templates and content classes to other servers. There is e.g. SitePort (http://siteport.net , can also move whole templates between RedDot servers afaik) and the Sync Tool (http://www.erminas.de/en/products#synctool , can compare and move single element attributes and/or single lines of templates, please note: this shall not be advertisement as the tool is made by us but I do not know any other like this). Some companies also have custom development tools for this.
I have a local Sitecore instance where I made changes involving both code and the creation of a new sublayout.
After deploying the code I can see on the new environment the usercontrol (.ascx) file associated to the sublayout, but the corresponding item does not appear and cannot be used.
If I attempt to recreate the usercontrol, it tells me that the file already exists, and due to my lack of experience with the platform I found myself unable to import it.
What would be the optimal way to proceed?
To deploy your new sublayout correctly you should create a Sitecore Package. This is basically a zip file that allows you to move both items and disk files between Sitecore instances in a controlled manner. For basic installs of Sitecore, where you have not added any specialised tools, it is generally the preferred way to move resources between servers.
The "Package Designer Guide" on the Sitecore Developer Network will give you information about how to use the Sitecore UI on your development site to create a package containing both the Item(s) and the file(s) for your sublayout:
http://sdn.sitecore.net/upload/sitecore6/65/package_designer_admin_guide-a4.pdf
Once created, this package can then be imported onto whatever other servers you want to deploy your sublayout to.
-- Edited to add --
Derek Hunziker's answer makes a good point: As well as the basic Sitecore behaviour there are third party tools available which can enhance and extend the deployment experience if you wish. As well as Hedgehog TDS, you might also consider:
The "Sitecore Rocks" extension for Visual Studio allows the creation of packages from within the
Visual Studio UI. This tool is free to use. (https://visualstudiogallery.msdn.microsoft.com/44a26c88-83a7-46f6-903c-5c59bcd3d35b/)
There are also a variety of open source tools - Sitecore Courier is one example: (https://github.com/adoprog/Sitecore-Courier) This is designed to help automate deployment between Sitecore instances.
Both TDS and Courier are most suited to regular deployments, such as those during ongoing development cycles, since they both include automation to help decide what gets deployed. The standard Sitecore UI and the Sitecore Rocks extensions for package creation are better suited to ad-hoc deployments, since you generally pick the things to deploy manually.
A common best practice is to deploy your items along with your code using Team Development for Sitecore. This eliminates the need to create Sitecore packages every time you want to move items between environments, which in turn reduces issues caused by human error. As an added bonus, the items that you own as a developer (such as Templates and SubLayouts) can be checked into source control.
Full disclosure: I work for Hedgehog Development :)
I have started using Git for my other development projects (PHP, HTML, JavaScript, etc.) and can now see how beneficial it is, however I've been unable to find anything similar for Dynamics CRM 2011/2013 as a lot of the solution development is done within the web interface.
I'm guessing this is not possible, but could someone with more experience than me please confirm this or let me know which tools I should be looking into?
Thanks
You can use the Visual Studio Developer Toolkit available in the SDK to version control your plugins and web resources initially. I'd recommend this as your first step.
If you choose to take it further you can also look at using the SolutionPackager tool to version control your solutions. This will split out your solution zip file into separate version controllable files for each component. It works best when you follow the developer workflow outlined in the linked MSDN article
In porting my WPF MVVM app to MvvmCross, what would be the recommended approach for persistent user settings in the Core assembly? Currently I'm using Properties.Settings for this task. Ideally, I'd like a solution that can play nicely with ClickOnce upgrades on Windows.
Thanks!
If you only want to support WPF, then you could continue using properties.settings.
If you want to support settings using native techniques on other platforms as well, then you could create an interface/abstraction for your settings and then use dependency injection to inject an appropriate settings implementation on each platform. You could do this in a plugin if you wanted to - but for getting started it's easiest to start by injecting this in your UI projects in Setup.cs (for how to build a plugin, see https://speakerdeck.com/cirrious/plugins-in-mvvmcross)
What I would probably do... is to use a portable settings implementation - either using a simple JSON file or using a small SQLite database (accessed via SQLite-net). This would enable you to reuse exactly the same code on all platforms. I don't know how this would work with ClickOnce (I don't know much about ClickOnce) but I'm assuming ClickOnce would preserve these data files during upgrades.
For portably saving a JSON file, see https://github.com/slodge/MvvmCross-Tutorials/blob/master/Sample%20-%20CirriousConference/Cirrious.Conference.Core/Models/FavoritesSaver.cs
For using SQLite-net, see https://speakerdeck.com/cirrious/using-sqlite-dot-net-in-mvvmcross - but be aware that the nuget packages for SQLite-net still suffer from the open issue on x64/x86/ARM differences - see How to distribute processor-specific WindowsStore assemblies with nuget :/