Ive never tried the CTRL+ options before but teh CYRL+/ didnt work for me either.
Im not sure that keyboard shortcuts is what you are asking for though as /* comments out anything below it and */ terminates the commented lines i.e,

set A=1

/*

set A=2

set B=A

*/

write A // (which now equals 1)
write B // (which now causes an error)
quit

Hi Kyle,
O.K. so I'm nearly 3 years replying to this post but none the less......
I agree that tune tables is a very necessary and useful tool in order to improve query performance.
Where it does fail in my opinion, much to my disappointment is that the tune table data is stored within the actual class rather than elsewhere. This causes a major tune table flaw for classes that are mapped over 2 or more namespaces as the tuning needs for one namespace could and often is completely different for the tuning needs of the other namespace.
Are you aware of any ways to get around this problem please?

Hi,
It would seem that your REGINUS database expansion size has been set to 1000, this can be checked via the SMP using System->Configuration->Local Databases and clicking on the relevant database link.
I would hazard a guess that your cachetemp database has an expansion size of 0 which is the system default hence why it is growing at a lesser rate.

If you run ^%GSIZE in the relevant namespaces then you will be able to see which globals are taking up so much space.
There is of course the possibility that you had work objects/globals being created that have since been deleted and therefore you could have a lot of empty space in your database. This can be resolved using both Database Compact and Truncate. These options can be found in the SMP under System->Databases and clicking on the relevant database link.
 

I personally would dismount and then take a duplicate copy of the relevant IRIS.dat or Cache.dat at an OS level, then mount them both as separate databases.

I would then delete the globals from 1 and then the the routines/classes from the other.

Then remove any inapropriate namespace mappings if necessary.

Hi Yone,
I would personally go for something like this:-

if $zd($system.SQL.DATEADD("yy",65,nacimientoFormateado),3)<+$h write "younger than 65"

if $zd($system.SQL.DATEADD("yy",65,nacimientoFormateado),3)>=+$h write "65 or older"

Assuming that nacimientoFormateadois in an ODBC format i.e. 2021-06-22

Hope that helps.

Not sure if any of the replies are resolving your issue yet but a long winded but definite way of achieving your goal would be to load the data values into a incrementing global i.e. set ^SQLWK($i(SQLWKvariable))=SQL values. You can then run down the global instead of your query result set.

Hi Evgeny,

I agree. We use a UnitTest package for everything UnitTesty. We keep all of the UnitTest classes in a UnitTest namespace/database and map them to our live namespaces.

I'm  not too sure about accessing different namespaces via SQL but you can use a variety of %ResultSet objects but personally I prefer using an SQL cursor with SQL open, fetch to iterate through the object.

My 'personal' reasons for preferring SQL cursors is that they are extremely fast to develop but more importantly if you add/remove indices in the target class then the class that uses the cursor will use the best available indices without requiring re-compilation unlike at least some of the %ResultSet methods.

jim

In that keep as is and get your login page to redirect to your home page upon successful login.

Jim

On the Management Portal under System > Security Management > Web Application > Edit Web Application set the Login page to that of your home page.

It forces users to that page web they come to your site.

HTH

Jim

Hi Sansa,

Its not neccessarily the prettiest way to do it but this wil work :-

U file w $select(name[",":$c(34)_name_$c(34),1:name)_","_$select(details[",":$c(34)_details_$c(34),1:details),!

Personally I would use $c(13,10) as an end of line marker rather than "!" as using "!" can have issues with certain software/operating systems.

Steve