Eduard - I think Arcady was asking from a purely data-processing perspective. I.e. if you are already have a bunch of in-memory data and need to process/iterate on it, is it better to stick it in traditional structures and use $Order, or is it equivalent to stick it into the new structures for iterating and processing? I think it's a good question and I would also like to hear what people think :)
I should have searched just a little longer.
obj.%Reload()
I found this in Documatic for my class (inherited because it is persistent)
Vitaliy,
Thank you very much for the working sample - I really appreciate it!! In the end I decided to go with the approach of just projecting the property from the container into the embedded obj because it ended up being better for my particular project. If I have to revisit this in the future because I need more than just that one property, I will definitely try out your example!
Thanks again,
Ben
Thank you all ... sometimes all it takes is a good night sleep :)
I figured out to avoid recursively updating the value via the trigger .... don't update it if I don't need to :)
Here is my code - it now works like a charm!
Trigger TUpdateFoobar [ Event = INSERT/UPDATE, Foreach = row/object, Time = AFTER ] { Try { // get value of Foobar NEW fb SET fb= {Foobar} // INSERT value into embedded foobar, *only* if it differs from Container value If (fb'={InnerObj_Foobar}) { &sql(UPDATE ContainerObj (InnerObj_Foobar) VALUES (:fb) WHERE %ID=:{ID}) } } Catch tError { Do LOG^%ETN Throw tError } }
I have been trying this approach but I am hitting a wall. It appears that because I am inserting the value into the embedded object in the container, it is seeing this as an additional UPDATE and calling the TRIGGER again, resulting in a <FRAMESTACK>. Any ideas on how to prevent the <FRAMESTACK> error?
Here is my simplified code:
thank you for the time you took to look! I thought that UPDATE SQL rights might be sufficient.
Thanks again and have a great night!
Agreed - this could be very dangerous if not used carefully. Fortunately in my case it's a training VM where all users are created programmatically :)
Do you have any idea on the minimum privileges required to select or update the Security.User table?
Thanks again for your help!
This is for an exercise I'm creating for updating users via SQL. It is for educational purposes only and isn't going to be anything used in production
Thank you Gilberto!
Any idea what resource is required to do this? Is it just granting UPDATE rights on the Security.Users table? Or is there a DB Role (limited - not %All or something crazy like that) which will allow this to be run?
Ben
Fanny,
You really should work with your InterSystems account manager and Sales Engineer to look into the details. This really isn't a forum that covers the TrakCare product.
All the best!
Ben
Sounds like it's necessary to start fixing some bugs if there are that many errors thrown ;)
Is this more for debugging / tracing data that you are generating that volume of events?
Most welcome! I find it extremely useful in my dev.
If you call LOG^%ETN it will dump all of the stack into the Application Error Log which you can access via the management portal or the terminal.
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=ATRYCATCHFAQ has some discussion on LOG^%ETN which may be helpful.
Ben
Kumar ... I reached out to your account team and they are setting up a call so we can discuss this directly. We'll help you find a good solution for this!
NOTE: See this new article I threw up from Global Summit content I presented a few years ago for more ideas on differentiating Testing and Production environments:
https://community.intersystems.com/post/managing-many-environments-and-protecting-production
Also, Classes lend themselves much better to programmatic access and manipulation of their content (you can do this with routines too but it is harder to do so due to their unstructured nature).
For example, the server-side Source Control hooks we use can programmatically insert an RCS Keyword as a class parameter ("SrcVer") into any class which doesn't already have it defined. This is extremely powerful because it allows source control to create an automatic 'watermark' in every class created for our internal applications which can be programmatically access or from terminal:
SSO>write ##class(AppS.WebClient).#SrcVer $Id: //custom_ccrs/us/ISCX/SSO/BASE/cls/AppS/WebClient.xml#6 $
This would require much more plumbing to do automatically with a routine!
Making further changes to the SMP banner isn't supported unfortunately.
In the Management Portal go to:
System > Configuration > Memory and Startup
Change the System Mode and it will put a custom banner in the header indicating Dev / Test / Live
Kumar,
It sounds like you are trying to use Atelier with client-side source control hooks against a shared development instance - is this correct? If so, you are bound to experience frustration with this due to consistency issues.
Please review https://learning.intersystems.com/course/view.php?id=713 which discussed the 4 modes of development, which are to be avoided, and options available to you in a summary graphic from the training:
If you are going to be using Atelier with client-side hooks, I *strongly* recommend you move to giving each developer their own private instance to test against.
John - thank you for the update on this one. The request# hadn't been on my radar but now it is and I am seeing what I can do to escalate internally (no promises though).
Cheers,
Ben
Kumar,
If you are using CCR then there are very specific requirements in terms of development workflow which will provide assurances of no source loss, etc. Please open a ticket with Support to discuss these specific concerns and considerations.
In summary, there can only be a single Disconnected BASE environments for each System, because the CCR Client Tools manage source concurrency within the Namespace, and if you have multiple BASE namespaces you have lost concurrency and therefore can lose source. Atelier will work the same as Studio - you need a single Shared Dev Namespace using the CCR Client Tools (aka server-side source hooks) and at that point you can use either Atelier or Studio to edit the source in BASE.
IMPORTANT NOTE: Server-side hooks will only work properly with Atelier if you are running a database version that includes CDS2924. This is included in 2016.2.3+, 2017.1.2+ and 2017.2.0+ only. If you are not sure if you have CDS2924 or not, please contact Support (if you use Atelier against a Shared Dev instance that doesn't have CDS2924 you don't have concurrency and therefore can lose source).
Hope that helps to get you started in the right direction :)
There are lots of things to consider when working with shared dev and Atelier. I highly recommend that you take a look at this session from the last Global Summit which should help to clarify the issues and help shape your options:
Thank you Mark - much appreciated.
You would also need to be careful of the following:
You must be very careful that your non-production instances do not behave as production post-cloning (e.g. you would never want a test system generating emails to non-developers). We have all of our code-base instrumented so that with a single configuration global we can control production vs non-production behavior (including where to go for web service calls, etc). This allows us to have identical code across all environments, but only Prod will send email, fetch actual user files, insert real data into other systems, etc. We then have our application-specific configuration globals mapped to their own Config DB, which means:
Glad to hear that you are already virtualized - that can really save you a lot of setup and config time. Let me know if you have any additional questions :)
(P.S. Chris, welcome to the world of Caché and DeepSee!! I hope you find the Community to be helpful.
note - if you are happy with this answer, please mark the Answer as Accepted so this thread falls off of the Unanswered Questions list)
For my team we always deploy on VMs, which makes it trivial to clone the VM to create our Dev and Test instances (this helps ensure complete equivalent for all Caché settings, OS patch level, OS settings, etc). When we moved to this approach it really helped to improve our testing stability and predictability (we have our Code and Data separated into different DB, so the Code DB is updated from source control and our Data DB can be updated weekly with restoring the backup of the Prod Data DB.
If you are currently deployed on bare iron this won't be an option for you. But if you are virtualized for production (or can move to it in the future) you may find that it saves a lot of hassle for your Dev and Test instances.
Alexey,
The post you referred to was with respect to license key changes - I didn't see any guarantees that a previous non-Ubuntu installs would be upgradable (in fact I would be surprised if they were).
I suggest you contact the WRC for final confirmation, but I expect you'll need to start with a fresh instance and move over your code, config and data.
Ben
You are looking at the download site for free copies of the software for evaluation.
Supported customers can download the Ubuntu kits from the Distributions page in the WRC:
https://wrc.intersystems.com/wrc/coDistribution.csp
Contact your account manager if you don't have access and think you should.
Geoffroy,
Welcome to Caché!
Moving a database is really straightforward:
Hope that helps!
Ben
See this thread which discusses several options for server-side Studio hooks for Git:
https://community.intersystems.com/post/are-there-server-side-git-studi…
NOTE - in my use-case I was looking for server-side hooks in order to allow concurrent server-based development, and I discovered that Git is very poorly suited for that purpose. I ended up abandoning Git and using Perforce instead for my demo (Perforce is very well suited for server-side hooks with concurrent server-based development). If you are you already operating in a single-developer / single instance setup and if you can move to one of the very latest versions of the product (2017.2.0+ or 2017.1.2+) then you should take a look at Atelier with client-side source control hooks.
For a thorough review of the different development models (private instance vs shared instance) and the different source control hook approaches (client-side vs server-side), I highly recommend that you watch the following session from last year' Global Summit:
Stephen,
An advantage to this is that the WRC will have a history of snapshots of your config and some basic operating data so that if you need to contact them about a performance issue, behavior change, etc, they could look back and see changes which have taken place in your system that might impact current behavior.
Several large customers take advantage of this to make it easier to see trends in their instances.
HTH,
Ben