that first line is required to initialize the mbChunk variable used in the loop, else you'd get an UNDEFINED at runtime.

I'm thinking the way how you're using this macro is slightly off, and this has the same root cause as the other thread you opened. This macro is expected to be used on its own:

  // some logic here
  $$$AndBits(^glo1,^glo2)
  // more logic here, and note there's at least a space before all these lines

hope this helps

Hi @José Pereira , you can use the maxerrors flags in a USING clause to bail out earlier, though I'm guessing you're actually already using it to achieve the opposite and make sure you process all the correct rows. 

We're intentionally writing verbose logs as that was an explicit request early on. As for retention, that was overlooked in the initial release, but is a roadmap item to make this follow the existing PurgeErrors CPF setting (and I'll add a note to the ticket you brought it up). In the absence of that, you can just use DELETE or TRUNCATE on these log tables.

right, I was misled by the error message, which is the same for what you'd get if you omit that initial whitespace.

Given that is your macro use, the error is because the expanded statement (which you can see from the generated .INT code) is invalid:

set a = if %arr>0 QUIT 5

A macro gets expanded before code gets compiled, and should not be mistaken for a function call.

If you want to use that macro on the RHS of a set command, you'll need to rewrite it into something like $select(%arr>0, 5, 123).

Here's an example that combines two bitmaps:

#define AndBits(%dst,%src) ##continue
    set mbChunk=""                                      ##continue
    for {                                               ##continue
        set mbChunk=$o(%dst(mbChunk),1,mbBits)          ##continue
        quit:mbChunk=""                                 ##continue
        set mbBits=$bitlogic(mbBits&%src(mbChunk))      ##continue
        If $bitfind(mbBits,1) {                         ##continue
            Set %dst(mbChunk)=$bitlogic(mbBits)         ##continue
        } Else {                                        ##continue
            Kill %dst(mbChunk)                          ##continue
        }                                               ##continue
    }

Using ##continue helps you avoid cramming everything onto a single line

I agree it's become more of a style preference thing, so absolutely something to have strong opinions and religious debates about :-)

The only thing to avoid is using Dynamic SQL to conveniently build your query and then feed in query parameters through string concatenation rather than as true ?-style parameters. That's a security risk you wouldn't run with Embedded SQL. That's all. Back to the debate! :-)

That REST API is indeed for querying iFind indices (hence the direct reference to an index you can provide) and the somewhat confusingly named "query" argument is actually to pass in the iFind search string. The API will then build a full SQL query for you and run it right away. 

Here's the OpenAPI spec for this endpoint (from self-documentation endpoint /api/iKnow/v1/USER/swagger):

  /table/{table}/search:
    post:
      operationId: /table/{table}/search-POST
      summary: |
        Search the given iFind index in the given table
      tags: ["iFind"]
      parameters:
        - $ref: '#/parameters/tableParam'
        - name: RequestBody
          description: JSON object with a list of query-specific arguments
          in: body
          schema:
            type: object
            properties:
              query:
                description: This is the only necessary parameter with no default value. The search terms to query against the iFind index.
                type: string
              index:
                description: the iFind index would be searched against, if you don't specify it, the first found iFind index would be used .
                type: string
              option:
                $ref: '#/definitions/OptionSpec'
              distance:
                description: only valid when option is fuzzy search (when option is 3)
                type: string
                example: "3"
              language:
                description: iKnow-supported language model to apply, for example "en"
                type: string
              includeText:
                description: whether the returned columns should include the column beging indexed by 'index'
                type: integer
                default: 0
                enum: [0, 1] 
              columns:
                description: specify the columns which also needed to be returned. For example, ["column1","column2"] 
                type: array
                example: []
                items:
                  type: string
              highlightSpec:
                $ref: '#/definitions/HighlightSpec'
                description: the parameters needed for Highlight
              rankSpec:
                $ref: '#/definitions/RankSpec'
                description: the parameters needed for Rank
              where:
                description: the valid SQL logical condition statement. For example, "column1 = ? AND column2 = ?"
                type: string
      responses:
        200:
          description: Successful response
          schema:
            type: object
            properties:
              rows:
                type: array
                default: []
                items:
                  type: object

Love the article! Very well-phrased considerations on the use of AI, almost all of which I share. Especially in the context of #1, we should not forget that the second L in LLM is for Language, and not for Fact or Solution (otherwise it would be a really bad acronym!). Therefore, if we're not qualified to spot what hallucinations crept into the response, its nicely-phrased language will probably make sure we never will.

PS: so glad you passed that Stats test and joined InterSystems :-) 

I believe what you're looking at is the new, more fine-grained set of %Native_* resources you need to use native functions. Look for DP-423341 in the upgrade guide. It seems we failed to describe this requirement in the  Native API documentation (or at least I didn't find it where I expected it), so we'll get that addressed.

I'd also recommend defaulting to the new, dynamic upgrade guide that makes it easier to filter on particular types of issues. This is now replacing the old, static pages that were more reliant on / vulnerable to manual curation. In fact you'll no longer find those static pages from the menu in the 2025.1 doc.

Any tools that use SQL to access partitioned tables will just work, as from the SQL query perspective there is no change. This includes Adaptive Analytics, InterSystems Reports, and any third-party BI tools. Also, IRIS BI cubes can use partitioned tables as their source class.

We currently have no plans to support partitioning of IRIS BI cubes themselves, as they have their own bucketing structure and less commonly have both hot and cold data, so some of the motivations for table partitioning don't apply.