All
Accepted answers
Kyle Baxter · Jan 26, 2016 go to post

While I don't think there's a 'good' way to do this, I think your approach might work.  Say you have two Namespaces, A & B.  You can link Ens.MessageHeader & Ens.MessageBody from B to A and then run the query:

SELECT <Fields> FROM Ens.MessageHeader WHERE (...)

UNION ALL

SELECT <Fields> FROM Ens.MessageHeaderB WHERE (...)

While this will work (technically) it is limited.  You won't necessarily be able to JOIN, ORDER, or GROUP the results in a meaningful way, and so you will need to write some additional code to do this.  That said, you could certainly write a stored procedure to handle this situation if you so chose.   The stored procedure here is more in line with what Dave L. said - you need to write code to merge the results.  But if you don't care about order and you think you're only going to get a small number of messages back, no reason this can't work.

Kyle Baxter · Feb 2, 2016 go to post

Hello Jack,

Your query should be:

SELECT * FROM my_table  WHERE %ID %FIND search_index(IDXBASDescriptionDemande,'éléments',1)

To get stemming to work.

Kyle Baxter · Feb 2, 2016 go to post

Hi Jack,

Sorry, lost half the email.  The second problem is that you are searching for:

'Elément'

instead of

'Élément'

which iFind reports as different words (indeed, they do NOT match). 

Cheers!

Kyle

Kyle Baxter · Feb 11, 2016 go to post

This is working as expected (to the best of my knowledge).  If you have a property that is SqlComputed and not Calculated, then the property value is stored on disk.  We calculate that value to store it on disk and do so on the first INSERT/%Save().  Then, since there is no SqlComputeOnChange value, the value won't be re-computed on any UPDATEs.  However, I believe you will be able to set that property directly via INSERT/%Save(). 

Kyle Baxter · Mar 15, 2016 go to post

There is no  Requirement for bandwidth that I'm aware of.  Studio uses ODBC to connect to the Server, and it will have to bring over the class/routine list in order for the open dialog to work, and if you have a large system this can take some time.  I think as long as Studio is getting information, though, that it should work (albeit slowly).  If you find Studio is working too slowly, you can import your project to a local instance and work off of that. 

Kyle Baxter · Jun 7, 2016 go to post

This was my thought.  If you use CacheSQL Storage not only do you pick up the JSON functionality you want, you also get SQL and Objects access, allowing you to take full advantage of the power of Caché.

Kyle Baxter · Jun 9, 2016 go to post

Hey thanks for posting this!  

And no matter what you say, I WAS NOT laughing at you (though I may have been laughing)!  cheeky

Kyle Baxter · Jun 30, 2016 go to post

Have you tried refreshing the catalog?  If that doesn't work I suppose it could be a permissions issue.  If you want to pick up an ODBC log I'd be happy to review it.

Kyle Baxter · Jun 30, 2016 go to post

You can enable the ODBC log by going to the 32-bit Driver Manager (C:\Windows\sysWOW64\odbcad32.exe) and opening your DSN.  Click 'ODBC Log' which is a checkbox in the bottom-left of the screen.  Then open WinSQL, and refresh the catalog, and close WinSQL again (this last piece forces the log to flush out of buffers onto disk).  The log file will be in C:\Users\Public\Logs\CacheOBDC.log.

Kyle Baxter · Jun 30, 2016 go to post

 Looking at the log I see:

DSN: TH_T2016_PRE-LIVE
    USERNAME: 

So you are logging in as unknownuser?  If so, does that user have permissions?  

Kyle Baxter · Aug 1, 2016 go to post

If you are going to do all the $C's, then you should definitely test $C(0) as well.  Was that "" (empty) or " " (space)?  I think you should test both.  And also probably test with a longer string - something like 600+ characters (limit for subscripts), 33K characters (normal string limit), and perhaps even try to blow out the string stack and make sure things are handled "properly" (whatever that means for you). 

Kyle Baxter · Aug 30, 2016 go to post

Great question!  The reason is that count(*) will read the smallest index, so having an index on ANY field made the count go quickly.  So the customer had an indexed field that helped here, but not in general. 

Kyle Baxter · Sep 7, 2016 go to post

You can starting in 2016.2!  Check out the field test and try it out!  We want people who have Eclipse experience to help us make our new IDE as smooth and easy to use as possible.

Kyle Baxter · Sep 9, 2016 go to post

Excellent question.

Of course, when you are going to be using iFind it does mean a heavier burden for your INSERT/UPDATE/DELETE functions.  It also does take up more space on disk than a traditional index.   The cost is going to depend on what kind of iFind index you are using and the size of the data being indexed.  For my example an insert went from about 5 global references to about 200.  But that is, of course, still fast due to the way Caché manages writes to disk.  On INSERT went from 0.0002 seconds to 0.0032 seconds.  So significantly slower, but still plenty fast.  If you test a use case and come up with something different, post it here!!!

Kyle Baxter · Sep 10, 2016 go to post

This deserves a full answer that I will give on Monday - just want to put this here as a placeholder.  But, spoiler, iFind is better.

Kyle Baxter · Sep 10, 2016 go to post

Ah licensing - I should have covered that.  This does require an iKnow enabled license, but one of those should be easy to obtain, at least for development purposes.  Just contact InterSystems or your already assigned sales representative.  

Kyle Baxter · Sep 21, 2016 go to post

Jason - if you haven't sen Dave's response below, please do so.  If you want this investigated further I recommend opening an issue with InterSystems Worldwide Response Center (WRC... a.k.a. Support Department) by going to wrc.intersystems.com.  We would be happy to help you figure out what happened, why it happened, and how to prevent it in the future.  

Kyle Baxter · Nov 21, 2016 go to post

Sure - you can try to merge it off before deleting it:

m ^KMB = ^%sqlcq("NSP","SMPQueryHistory")
 

And then you have your query history in a different global, which you can reference when needed.

Kyle Baxter · Dec 15, 2016 go to post

I actually baked a cake to commemorate this occasion, and totally not because I'm fat and wanted cake.

Kyle Baxter · Dec 15, 2016 go to post

If you want to investigate the performance of the query you can always open a WRC Case (wrc.intersystems.com :-D).
Otherwise, send out your class definition and query plan and I can take a cursory look at it.

Kyle Baxter · Dec 28, 2016 go to post

I think the best way to do this would be to write something in COS, write a class query with it, and use that as a Table Valued Function.  While there might be a relational way to do this, it seems like it'd be messy.

Kyle Baxter · Apr 20, 2017 go to post

Using the macros is a bad idea.  The changes to the JSON, especially in this case, are simple.   Any source control system worth its salt is going to be able to make nearly all of the changes for you automatically.  As far as I know the only change that can't be caught by find-and-replace is the one requiring COS expressions embedded within JSON to have parentheses.  In this case, the new syntax is supported in 2016.1 JSON, so you wouldn't even need to change that.  Because of the ease of change, the fact that the change only needs to happen once, and the code obfuscation that occurs when adding  macros, I do not think using them is a good idea for anyone planning to use Caché's native JSON implementation.

Edit: It occurs to me that the macros would be useful if you have to switch back and forth between 2016.1 and later versions over and over again, but to do the conversion once is too simple to bother with macros.