go to post Benjamin De Boe · Jan 2, 2020 In addition to the suggestions made earlier (to provide more context such as full query & plan), you may also want to consider POSIXTIME as the data type for your date / time columns. It encodes dates as a simple 64-bit integer, which makes for efficient storage, indices and queries.
go to post Benjamin De Boe · Jan 2, 2020 Could you share the rest of the error message (hidden behind the alert) and more specifics on the ODBC connection type? And is there anything special about these tables or do you get this for each and every table?
go to post Benjamin De Boe · Nov 29, 2019 No, we indeed don't support that syntax feature. Like Evgeny said, this recursion is something we'd typically try to wrap inside ObjectScript methods, which you could then expose as a stored procedure.
go to post Benjamin De Boe · Sep 9, 2019 how about CASE :path WHEN '' THEN 1 ELSE $LENGTH(:path,'.')+1 END
go to post Benjamin De Boe · Sep 6, 2019 InterSystems IRIS (and Caché before that) will indeed make this decision for you. The SQL optimizer will analyze all the conditions in your query and select the best query plan based on the available table statistics, which includes column selectivity. See also this article on collecting those stats with the TuneTable command.As a matter of fact, our development team is making some exciting enhancements to the cost functions used to turn those table statistics into the actual cost estimates for the possible query plans. More about that at our upcoming Global Summit!
go to post Benjamin De Boe · Jun 17, 2019 Hi Guillaume,iFind indices, like bitmap indices before, require a bitmap-friendly ID key (positive integer). When you make a table the child in a parent-child relationship, the underlying storage structure will use a composite key that therefore no longer satisfies the bitmap friendliness. We do plan to lift this limitation in a future release, as it's already the case for bitmap indices, but for now you'll have to review your schema and see if a one-to-many or (preferred) foreign key would work for you.Thanks,benjamin
go to post Benjamin De Boe · May 16, 2019 Triggers expressed in SQL cannot contain a DECLARE clause, but you'd get a lot more flexibility when using ObjectScript triggers. See the reference documentation for more details.
go to post Benjamin De Boe · Apr 15, 2019 No, iKnow doesn't extract text from RTF prior to its NLP task. Besides the LibreOffice suggestion, I've also heard people who've worked with simple Java RTF extractors (part of regular JDK) and Tika in the past.
go to post Benjamin De Boe · Apr 11, 2019 Horita-san,not sure whether you mean the projection (table) itself is missing or the row you created through the API isn't showing up. This works fine for me, but in order to combine the use of APIs with a domain definition, you have to set the allowCustomUpdates flag to true (off by default). See also the notes in this article on the dictionary builder demo. When set to false, the API methods like CreateDictionary() will return an error (passed by reference, the returned ID will be below zero to indicate a failure).Hope this helps,benjamin
go to post Benjamin De Boe · Mar 21, 2019 There is a simple regression calculator that is used internally for similar trend line work, iirc. The class reference is not spectacularly elaborate, but it's fairly straightforward to use. First you use the add() function to load up points and then the result() function will calculate a simple trend line and populate Slope and Intercept properties: USER>s stat = ##class(%DeepSee.extensions.utils.SimpleRegression).%New() USER>w stat.add(0,1) 1 USER>w stat.add(1,2) 1 USER>w stat.result(.b,.y0,.r) 1 USER>zw b,y0,r b=1 y0=1 r=1 USER>w stat.Slope 1 you can keep adding data and re-calculate: USER>w stat.add(1,1) 1 USER>w stat.result(.b,.y0,.r) 1 USER>zw b,y0,r b=.5 y0=1 r=.5