go to post Benjamin De Boe · May 20, 2020 For more about where the source code for embedded SQL has gone in 2020.1, please see this article on the Universal Query Cache Indeed funny the doc doesn't call out table names while it does talk about field names, probably because it silently assumes the one implies the other. I'll ask our doc writer to fix that. Thanks for the notification.
go to post Benjamin De Boe · May 11, 2020 Depends on how you're set up. There is a setting to allow specifying those values that is meant for this type of bulk load scenario. @Daniel Buxton : the multi-row insert syntax you're asking about is currently not supported by IRIS SQL (as you figured by now :-)). Robert's approach using UNION all is a creative workaround, but depending on where your big INSERT is coming from you might also just be able to generate / rewrite it into separate INSERTs? Once you have that in place, you can use the SQL Shell's RUN command or the ObjectScript $SYSTEM.SQL.DDLImport() method to execute your script file.
go to post Benjamin De Boe · Apr 27, 2020 I don't want to discourage creativity, but this approach feels very risky to me. When you issue any SQL against this table before setting the % variable, it's going to cause ugly errors or unpredictable behaviour. I also wouldn't bet my money on this working in all possible parallel query execution scenarios (likely some, likely not all). FWIW, within InterSystems development, we typically call % variables that survive between method calls a leak rather than single-rivet-keeping-your-skyscraper-together :-). Again, apologies for putting it a little strong here, but I think most use cases asking for flexibility can be addressed with more robust solutions, such as temporary tables, class inheritance (with the NoExtent keyword), etc.
go to post Benjamin De Boe · Apr 27, 2020 If you need a programmatic entry point for dealing with complex filter conditions, take a look at %SQL.AbstractFind. It allows you to invoke ObjectScript code to populate bitmaps based on (any number of) user-provided arguments through a %FIND predicate. It is built on by iFind and this older (but worthwhile) community article on custom spatial indices, although in both cases it works hand-in-hand with a custom index (using %FunctionalIndex). That isn't required, but usually the flip side of the same use case coin.
go to post Benjamin De Boe · Apr 22, 2020 Hi Hansel, at Global Summit 2019, we already showed some early prototypes of our forthcoming System Alerting and Monitoring tool that also leverages Prometheus and Grafana to monitor your IRIS deployments (recording is here). It's still a few weeks away, but this Tech Talk will discuss this subject in more detail. Thanks,benjamin
go to post Benjamin De Boe · Apr 15, 2020 coming late to the party, but just as a small and likely irrelevant note: if you use a PPG for storage and at some point (because the table appears big) the query optimizer thinks it's worth using parallel query execution, it won't see a thing in those worker processes. You should be able to avoid that using the %NOPARALLEL keyword though.
go to post Benjamin De Boe · Mar 15, 2020 In addition to Eduard's response: sharding is a feature of our SQL / Objects layer. Raw globals are at a level below what we'd need for hooking in the workload distribution you're referring to.
go to post Benjamin De Boe · Mar 15, 2020 indeed, system schemas (whose name starts with a % sign) require certain privileges (that you quickly get used to once you have them :-) ). That's why I suggested querying the INFORMATION_SCHEMA
go to post Benjamin De Boe · Mar 13, 2020 and if you prefer something more database-independent, you can use the standard INFORMATION_SCHEMA package: SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME LIKE 'PATID%'
go to post Benjamin De Boe · Mar 11, 2020 FWIW, you can just put as many conditions as you want in the same SQL query. InterSystems IRIS includes an excellent SQL optimizer that will consider all the conditions (and other clauses) in your query and decide on the most efficient path to access the data.
go to post Benjamin De Boe · Mar 9, 2020 Indeed, that's the recommended SQL way of achieving what Eduard described about PPGs. Drawbacks are that queries on these tables cannot be parallelized (as that implies multiple processes, of course). Our TSQL support is meant for Sybase customers wishing to redeploy their TSQL applications on IRIS (especially now that SAP/Sybase is terminating support for those platforms). Just temporary table support by itself wouldn't be a reason to start building TSQL applications and abandon IRIS SQL/ObjectScript, of course :-). However, for a recent TSQL migration we did some work on our TSQL temp table support and were considering to roll that out to regular IRIS SQL, so this thread is a good place to share your experiences and requirements so we can make sure to do that properly, as needed.
go to post Benjamin De Boe · Feb 20, 2020 Hi Darko, LONGVARCHAR is actually storing the text as a stream, so to make LIKE work, you'll need to convert it to a string, e.g. using SUBSTRING(), in the expression you're serving to the LIKE operator. The following works fine for me: SELECT SUBSTRING(text, 1, 999999) FROM table WHERE SUBSTRING(text, 1, 9999999) LIKE '%abc%' This looks a little clumsy, but streams are really meant for huge data that wouldn't fit in a VARCHAR. Note that you can get a massive amount of text in VARCHAR (%String) columns these days, so maybe that's worth considering. Separately, when working with iFind, that'll provide faster search results and it also transparently takes care of the stream aspect.
go to post Benjamin De Boe · Feb 6, 2020 I didn't mind being lured into reading this excellent article, but the concept of "DataOps" is entirely different from what's being discussed here :-) You could also add the failed Ariana V 501 launch as an example of a case where conversion between units / data types caused somewhat costly trouble
go to post Benjamin De Boe · Feb 2, 2020 Hi Conor, We added a "cancel" button to the SMP in IRIS 2019.3 and are looking at an equally convenient mechanism from the shell.
go to post Benjamin De Boe · Jan 9, 2020 Also, which versions are you using (on the server and client sides)?
go to post Benjamin De Boe · Jan 2, 2020 That's what POSIXTIME does for you under the hood, so no need to require all your queries to be aware of this frugal innovation ;-)
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 · Nov 29, 2019 Besides the elaborate earlier answers about the actual interfaces under (or at) the hood, maybe a simple question to ask is which version you're on. If I'm not mistaking, that SELECT option was only added some 5 years ago and because the word "legacy" shows up on this page, I thought it's worth checking too ;-)
