Did you enable HTTPS on your webserver?  If so, that typically means a new port (default: 443), which you would need to add to your connection.  If not, do you know how to enable HTTPS on your webserver?

If ever you are looking for generalized information, you can always look at learning.intersystems.com as well as the documentation (docs.intersystems.com).   There's a lot of good videos there that you can use to help get going.  If you have any specific questions there are plenty of us who would be happy to answer them.

Hey Laura!

OK so if Frozen Query Plans was your problem (and it's a good hypothesis), then unfreezing them all gets you back to the old behavior (you'll need to recompile and purge cached queries).  There were some problems with the 'old' dynamic SQL classes, but I think those were solved, so you shouldn't have any problems going forward.  So let's talk about this a bit.

What are Frozen Query Plans?
If you've ever upgraded Caché and had a critical query degrade in performance, you'll agree this technology is pretty cool.  What it does, is to lock down your query execution plan during upgrades (or it can be user [you're the user] initiated). 

Benefits: No bad surprises during upgrades
Drawback: No benefits from core improvements to SQL engine

Is it a problem to Unfreeze all plans?

No!  Of course not.  You will absorb some risk, but if you usually don't have problems then you will continue to not usually have problems.  If you unfreeze all plans you'll need to compile your application and/or purge cached queries.  To do this you can execute the following in your application namespace:

w $SYSTEM.SQL.FreezePlans(0,1,,.err)
d $SYSETM.SQL.Purge()

You can obviously look this up in the docs for more information.  If you have embedded SQL queries those would need to be recompiled.

Dynamic SQL Implementation
We (InterSystems) recommend using %SQL.Statement in lieu of %ResultSet for dynamic SQL.  When you ask if you should change, the answer is 'yes'.  However, this only fixes your problem because when you use %SQL.Statement it ends up being a slightly different query according to our Frozen Query Plan implementation.  It fixes your problem, but not the root of the problem.  %SQL.Statement is also fine to use for 'older' code.  Of course, if you don't want to change your code ("if it ain't broke"), that's understandable.

SELECT * queries

Running a SELECT * query is a bit of an edge case.  It is frequently better to list out your fields so your are only showing your users the data they are interested in.  Indeed, you can only run into this problem if it is a SELECT * query.  In general, list out your fields.

 

So that's that.  If you have any further questions, feel free to let me know :-)

I recommend you open an issue with the WRC.  We'd be happy to help you out here.

I'd bet my breakfast that your first line of code connects to a remote database, and that is failing.  Therefore, when you go to prepare your query, it is failing due to no connection.  Check the status code from your Connect() call and let us know what that says.

For an ACTUAL solution to your question - go to the SMP and to System Administration->Configuration->(CSP/Web) Gateway Management.  From there go to 'Default Parameters'.  The timeout you want to change is the Server Response Timeout.  If you are using the private apache you can also edit the CSP.ini file in <Install>/csp/bin/.  Of course, if this is a Production Systems DO NOT DO THIS OR I WILL FIND YOU AND SAY VERY MEAN THINGS!

Your IIS configuration maps /csp to the CSP Gateway, but your application is /myapp - so when IIS looks at /myapp, it doesn't know what to do so it tries to serve files off of your filesystem which, of course, it can't!

So your question now, no doubt, is why does it work through the private Apache server (57773)?  Well because the private Apache server is set up to ALWAYS send ALL requests to the CSP Gateway, and the CSP Gateway knows how to handle it.

There's another trick, too.  When you create your /myapp virtual application, make sure you create a new module mapping for *. REST requests do not have extensions so you need to be sending all requests to the CSP Gateway regardless of extension (or things won't work)!

If you are having any more trouble getting this set up, please feel free to contact the WRC and we'll be happy to help you get set up.  

The correct way to do this is with TO_DATE:

select TO_DATE('19850720','YYYYMMDD')

That will convert the text in the first argument (a string) using the format in the second parameter into a date, which will be displayed using the current selectmode.  Try this in the Management Portal.

You can use ##class(Ens.DataType.UTC).timeUTCtoLocal()  like so:

ENSDEMO>s utc=$ZDATETIME($ZTIMESTAMP,3)                

ENSDEMO>w utc

2017-11-03 14:44:15

ENSDEMO>w ##class(Ens.DataType.UTC).timeUTCtoLocal(utc)

2017-11-03 10:44:15.000

This works for me.  I used this class definition:

Class Test.JDBCStream extends %Persistent
{

Property Content as %Stream.GlobalCharacter;

}

And the following query form SQuirreL SQL on Mac worked fine:

INSERT INTO Test.JDBCStream (Content) VALUES ('A long String')

So I'm not sure exactly what you're doing.  Do you have code?  Examples?  

As Len stated yesterday, you should open a WRC Issue.

Edit: Sorry this post looks bad, the text editor on this site is awful.

Moderator: fixed

Post Moderator Edit: Still looks bad, lost the syntax highlighting, and being able to edit people's posts kind of ruins the point of an open forum.