Recently I came across a very strong statement to the effect that InterSystems.Data.CacheClient.dll library works fast because it does not open a TCP/IP connection, instead it works in the same process as a database. It made me pause for quite some time. Firstly because .Net Managed Provider, which utilises this library, opens TCP/IP connection to the database (and it is stated in the documentation "Using .NET and the ADO.NET Managed Provider with Caché"). And secondly, because as far as I know only eXtreme applications attach themselves to the process.
I am looking at converting to the new DynamicObject and DynamicArray classes to build JSON. Our current (homegrown) JSON library forces string representation of numbers too long because of errors we were seeing with long numbers being truncated on the client, I am hoping to accomplish the same with the new classes.
We do have a production including a SOAP.OutboundAdapter that make a request to a .NET WCF Service. The response from that service vary in size. When it come to large one, we talk about maybe 8000 records (with 6-8 attributes per record) in xml, the adapter always give a timout. Even if we put a high number of seconds or set -1. After 1 1/2h still nothing get back. It's just standing there and waiting for ever.
Our .NET developer have look at it (on the WCF-service) and from ther point of view they say that it seems like Ensemle can't handle such big responses.
Is there an InterSystems supported dotnet core library or community contributed repo on the horizon? At this time we are exploring installing the ODBC driver in our containers but would rather use more robust solution.
I am going to develop a ASP .NET Core Application. In that Hos can use IRIS Entity Framework. I searched but I couldn’t find IRIS Entity Framework for .Net Core . Please kindly help me to overcome this issue.
I know it is perhaps too vague question, but anyway:
Do you have experience from running a thick (preferably .NET) application in any of these modes - client installed locally, Terminal Server, Citrix ? Say, there are around 300-400 concurrent users using application.
I ran the below query in three different modes. Coordinated Universal Time is 5 hours ahead of Eastern Time so there is difference in value from column 1 and column 2 in ODBC, Display mode, but not in Logical Mode. By default the query executes in ODBC mode when we query the data from outside world(via ODBC connection).
I don't know why query 2 and query 3 outputs different from query 1.
Query 1. Ran in Logical mode, DATEPART() took in memory stored timestamp data(stored in UTC)
I have been trying to pass a %Global character stream back on a Soap Response has anyone one out there done it before please help with guide lines on how to achieve this thanks in advance just some working sample code and will take it from there thanks again
"SELECT * FROM wmhISTORYdETAIL" runs as a passthrough without asking for the DNS.
'SELECT Count([wmhISTORYdETAIL].[HistHMNumber] AS CountOfHistHMNumber FROM [wmhISTORYdETAIL] WHERE ((([wmhISTORYdETAIL].[HistMovType])='Receipt') AND (([wmhISTORYdETAIL].[HistMovDate])>=Date()-1) AND (([wmhISTORYdETAIL].[HistMovDate])<Date()));'
asks for the DNS but both are linked to a table that has the password saved.
While I can query the HL7 message class EnsLib.HL7.Message (EnsLib_HL7.Message for SQL) to my heart's content in the SQL Shell or the Management Portal's SQL page, I can't seem to SELECT anything other than ID/%Id from an ADO/ODBC client. Properties such as TimeCreated, Name, MessageTypeCategory, etc. all seem to prevent the query from ever completing EXCEPT when I provide the ID as part of the WHERE criteria.
This works fine in the Management Portal and Shell:
is there any indication that the .NET object representation of Cache objects (i.e. InterSystems.Data.CacheClient.dll) complies with .NET Standard? I'm planning to extend our existing .NET client/server solution with a mobile option by Xamarin Forms and can't find any significant hints in the internet.
I'm just fooling around a bit and made some expreiments with a REST API and a generic object-to-JSON tier: