You can call code from %Installer via Invoke tag (more on that).

To change journaling programmatically execute:

/// Change database journaling state.
/// dbDir - database Directory (can be passed relative to the current working dir)
/// journal - 1 or 0. 1 enables journaling, 0 disables it.
/// zw ##class(util.Test).JournalDB("USER", 1)
ClassMethod JournalDB(dbDir As %String, journal As %Boolean = {$$$YES}) As %Status
{
    quit:((journal<0) || (journal>3)) $$$ERROR($$$GeneralError, "Invalid journal value. 0 or 2 for No, 1 or 3 for Yes")
    set:journal=$$$YES journal=3
    set:journal=$$$NO journal=2

    new $namespace
    set $namespace = "%SYS"
    set db=##Class(SYS.Database).%OpenId(dbDir)
    set db.GlobalJournalState = journal
    quit db.%Save()
}

That said, any particular reason you want unjournaled databases?

Do you catch exceptions?

If not try this:

Try {
 Kill %objlasterror
 Set conn = ##class(%Net.Remote.Gateway).%New()  // No error here
 Set tSC = conn.%Connect("127.0.0.1", "55000", "NETTEST") // No error here
 Write:$$$ISERR(tSC) $System.Status.GetErrorText(tSC),!
 ZWrite %objlasterror 
 Set api = ##class(writetofile.WriteFile).%New(conn) //Here comes the error
 ZWrite %objlasterror 
 Set strFile = "d:\temp\example.txt"
 Set strInput = "Hello world"
 Set ret = api.FilePut(strFile,strInput)
 Set tSC = conn.%Disconnect()
 Write:$$$ISERR(tSC) $System.Status.GetErrorText(tSC)
} Catch ex {
 ZWrite %objlasterror
 Do ex.Log()
 Write ex.DisplayString(),!
}

%objlasterror  can contain more error information. Also check application error log.

Are you on 32 or 64 bits? Check Cache with:

Write $system.Version.Is64Bits()

.Net library should be compiled with the same architecture.

Some ideas:

• session ID - you're getting it with pAlertRequest.SessionId, no?
• date - get it from pAlertRequest.AlertTime
• namespace -wouldn't it always be the current namespace? Get it with $namespace

What other data do you need?

Also, please post your code as text.

You can reference it as a normal property (which it essentially is).

If it's a BO, BS or  simple BP:

set a = .."name_BO"

If it's a BPL process:

<trace value='process."name_BO"'/>

Press F7 in Studio to compile all classes in a current project.

In terminal:

do $system.OBJ.CompileAll()

to compile all classes.

I'd start with setting the credentials in connection configuration. Should be enough.

KILLdes is a record for kill of descendents journaled as part of a higher-level kill inside of transaction.
So it's a Kill command.

Follow these steps:

1. Change superclass from %Persistent to %RegisteredObject
2. Delete Storage part of class definition.
3. Compile.

Table should be gone after that.

If you already deleted the class in Atelier (and synced that change with a server) the the table would be gone too.

Use Send method:

Set httprequest = ##class(%Net.HttpRequest).%New()
Set httprequest.Server = "www.intersystems.com"
Set sc = httprequest.Send("PATCH", location, test, reset)

Use INSERT OR UPDATE:

INSERT OR UPDATE INTO  ocsGUMCHECDINFO
(CODE,DODATE,NAME,DAY,PURPOSE,REQUIREMENT,BEFORENOTE,AFTERNOTE,CNT,REPORT,CONSENT,CONTACT)
VALUES (#{code},#{doDate},#{name},#{day},#{purpose},#{requirement},#{beforeNote},#{afterNote},#{cnt},#{report},#{consent},#{contact})

I'd run a BS with SQL inbound adapter called every 86400 seconds. Query is some SELECT Count(*) ...

To get optimal WHERE condition you'll probably need to answer these questions:

• Are records immutable?
• Can they be updated?
• Can records be deleted?
• Can records be inserted for a past/future dates?

If it's a local table you can run BS without adapter and just use embedded SQL.

There are two use cases here:

• File is tied to a specific object (for example you have "Document" class and it has "scan" file). In that case you can use %FileBinaryStream property - as before getting the file you would probably open "Document" object first
• File is not tied to a specific object. In that case you can create a separate table "Files" that stores
  • link to file as a FileBinaryStream
  • hash
  • displayed file name
  • file path
  • user who uploaded the file
  • extension
  • size
  • any other attributes you need

It would always work faster compared to OS search.

Other notes:

• Files are immutable - if you're building an application where user can edit files, it's usually preferable to have immutable "files" objects and just create new file versions.
• File size limits - always define and check for maximum size.
• Extension limits - limit extensions user can upload.
• Storage - if it's a low volume inserts (<1000/day) store files in a folder = date, otherwise generate a new folder for each new thousand of files. These approaches can be combined: date/1, date/2 ...
• Hash name - I often store files where their OS name is their hash. This way I can quickly validate that file is valid and also it  solves the problems with non-latin characters.
• Never store files under names supplied by user. Acceptable filenames are: guid, hash (integer id should also be avoided).
• GZIP - in some cases using GZIP streams can save on space, especially if it's a text file. For example XML envelopes and such.

You can concatenate statuses with:

set sc = $$$ADDSC(sc1, sc2)

Or append statuses with:

set sc = $$$ADDSC(sc, sc2)

Installer manifest can call arbitrary code.

1. Mirrors can be managed via  ^MIRROR utility.
2. Can be manipulated via Config.Journal class.
3. You can configure automatic purging task and set a number of days to keep there. Docs.
4. Tasks can be created and modified programmatically. Sample. They could also be exported and imported. Community discussion.

What's your current locale? If it's not Chinese you may want to change it. Note that it significantly affects system behavior and you should understand the implications in such a change.

???? often indicates the data loss during encoding conversions consider this Cyrillic  example:

set t = "Привет"
 
USER>zzdump t
 
0000: 041F 0440 0438 0432 0435 0442                           Привет
USER>zzdump $zcvt(t, "I", "UTF8")
 
0000: 3F 3F 3F 3F 3F 3F                                       ??????
USER>zzdump $zcvt(t, "O", "UTF8")
 
0000: D0 9F D1 80 D0 B8 D0 B2 D0 B5 D1 82                     Ð.Ñ.ивеÑ.

Note the difference between question marks and the last output. Last output is just encoding translation, but the first conversion - into questions completely lost the information, so you need to look deeper.

You can try to modify TCP/IP IO table via ^NLS utility in %SYS namespace

do ^NLS
 
 
1) Display current locale
2) Select defaults
3) Change locale
4) Display loaded settings
5) Advanced

NLS option? 2
 
1) Internal tables
2) I/O tables
3) CSP files
4) Date, time and number formats
 
Category of defaults? 2
 
Items marked with (*) represent the locale's original default
 
I/O table              Current default
---------------------  --------------------
 
1) Process             RAW (*)
2) Cache Terminal      UTF8 (*)
3) Other terminal      UTF8 (*)
4) File                UTF8 (*)
5) Magtape             UTF8 (*)
6) TCP/IP              RAW (*)
7) System call         RAW (*)
8) Printer             CP1251 (*)
 
I/O table: 6
 
 1) RAW (*)
 2) UTF8
 3) UnicodeLittle
 4) UnicodeBig
 5) CP1250
 6) CP1251
 7) CP1252
 8) CP1253
 9) CP1255
10) CP866
11) CP874
12) EBCDIC
13) KOI8R
14) Latin2
15) Latin9
16) LatinC
17) LatinG
18) LatinH
19) LatinT
 
Selection for TCP/IP: 1 =>

Seems possible.

Do you want to download data from Dynatrace into Ensemble or to send data (i.e. alerts) into Dynatrace?

1. If you replace:

set sc=gc.SetParameter(hstmt,$LB(gc.PutData(hstmt,.temp)),2)

with:

set sc = gc.PutData(hstmt, "TEXT")

or with:

set sc = gc.SetParameter(hstmt,$LB("TEXT"),2)

What do you get?

2. Also in your original 4-parameter generated code the stream is bound via:

 s err=$zf(-5,%SQLGateway,62,QHandle,4,1,1,12,500,0,500)

which is equal to

set sc=gc.BindParameter(hstmt, 4,1,1,12,500,0,500)

In your new code you bind the stream with:

Set sc=gc.BindParameter(hstmt,2,1,1,12,0,0,-2)

Is it from some other generated code?

First you need to link the procedure, and after that you would be able to call it from your BO.

Connection is not license.  From docs:

• The Caché licensing system attempts to identify distinct users and to allocate one license unit per user. A user is identified by a license user ID, which can be an IP address, a username, a CSP session ID, or some other identifier depending on how the user connects.
• Multiple processes started by or for a single user share a license unit up to the maximum number of processes per user. If the number of processes exceeds this maximum, a transition occurs and Caché begins allocating one license unit per process for that user ID. The system assumes that if the number of processes associated with a user ID exceeds the maximum, multiple users are accessing Caché through an intermediary (for example, a firewall system), so additional license units are required. (Processes started by the Job command are counted under the user ID invoking the command.)
• Even if the number of processes under the user ID drops back under the maximum, Caché continues to allocate one license unit per process for that user ID. Only when all connections by the user ID are closed and there are no more processes under the user ID does license allocation reset to one unit for that user ID.

Maximum number of processes (connections) per user is 12.

Will this affect our own internal tasks?

It shouldn't as that would be one connection and license slot.Still, I'd recommend contacting WRC to clarify the issue completely.