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.

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?

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.

how about CASE :path WHEN '' THEN 1 ELSE $LENGTH(:path,'.')+1 END

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!

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

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.

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. 

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

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