If the second FTP server is in your local network, is it possible to map the drive to a local drive? Once you do this, in theory you should be able to directly download the file to the mapped drive without relying on ftp to download and then upload. 

If this process still writes the file to CACHE.dat then I would simply create a batch file in windows that can download the file into the mapped drive or local drive and upload if necessary, then run the batch file, either using windows task manager or task scheduler in Ensemble (RunLegacyTask) and use Do $ZF(-1,(batch file location)) or Do ##class(%Net.Remote.Utility).RunCommandViaZF((batch file location),,.rt). 

If the growing CACHE.Dat file is an issue then you can use Compacting and Truncating feature described here:  http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY…

That looks like you are trying to connect using a %SQLGatewayConnection. Can you post the preceeding lines of code? 

If so, make sure the DSN exists and can connect. The statement is correct for the desired database and the odbc drivers are correct for your system. 

Hi,

Your question is a bit confusing. Neither of those are valid HL7 messages. Do you mean that first $$$LOGINFO("Stream: " _ pInput.GetData(1)) is generating the first example message? In the first message you seem to only be getting back the first 8 characters from each line. Are there any limitations in the number of characters defined somewhere? 

The second one is due to the Schema being a default Ensemble one. From your message it seems like you will need to define a custom schema type according to your HL7 specification. 

Kind regards,

Alice

Passwords are encrypted so no.

Login details are stored in Security.Users table or ^SYS("Security","UsersD") global in %sys namespace. 

Another + for classes would be intellisense in studio. 

Although, I do like the public output variable list separation to input variable in mac files like so:

TEST (invar) [outvar] public {

}

Documentation states Set SharedConnection=1 and not Set ..SharedConnection=1. The implementation here is correct as Set SharedConnection=1 does nothing, so the documentation needs to be updated. 

If none of those above solutions work, it might be possible to use emergency login into the system. Then setup your own username and password in the management portal once in. 

1. Stop cache instance. 

2. Open windows cmd as "Run as administrator".

3. Browse to the bin directory inside the directory where you installed cache.

4. use the command 

ccontrol start <instance> /EmergencyId=<username>,<password>

Where instance is the name of your Caché instance, and type any username and password.

E.g: 

ccontrol start MyCache /EmergencyId=Eugenia,52601

Try to login using that and then setup a username and password and then restart Caché to login via the newly setup username and password. You can read more under "Emergency Access" here:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY…

A quick note from the documentation:

"%SelectMode

The LIKE predicate does not use the current %SelectMode setting. A pattern should be specified in Logical format, regardless of the %SelectMode setting. Attempting to specify a pattern in ODBC format or Display format commonly results in no data matches or unintended data matches.

You can use the %EXTERNAL or %ODBCOUT format-transform functions to transform the scalar-expression field that the predicate operates upon. This allows you to specify the pattern in Display format or ODBC format. However, using a format-transform function prevents the use of the index for the field, and can thus have a significant performance impact."

I'm not sure if this affects you but can you try:

SELECT lnkdid,
c_fastsearch_code,
c_drugfull
FROM JAC.drug_basic
WHERE %ODBCOUT(c_drugfull) LIKE 'Para%'

To answer your question via timed tests:

Query 1 (Iterating 100 million times...) :

Example 1 :

Example 2: 

Query 2 (Iterating 1 billion times!!!): 

Example 1:

Example 2:

@  Vitaliy Serdtsev (100 million iterations)

As everyone said, setting variables/ conditional statements is probably not where it's getting slow. As someone mentioned PERFMON is a great tool . Another one is ^%SYS.MONLBL. 

I just got too much bloody time .... 

If possible it's always recommended to use the  Caché  implemented predicates rather than the ANSI sql ones as they will normally always be faster. Execute the same queries in the management portal on large tables and you can verify those for yourself.

The list of those are here:  Caché  https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RSQL_PREDICATE_CONDITONS
 

I presume 1.4 in your case means 1.4 seconds to run the query that's causing the hyperevent error? Not always but sometimes I find hyperevent errors in synchronous processes having some sort of infinite loop somewhere in the code.

In the past to determine which part of csp is causing an issue I've used ^%SYS.MONLBL which is mainly used to log the amount of time each line in a routine (mac/int) takes to execute but since csp gets compiled to .cls and .cls gets compiled to .int you can add the .int part of the csp to monitor the csp. 

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cl…

Maybe something like this,

$SYSTEM.Process.UserName($ZJ(""))