NetTalk Central

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Bruce

Pages: [1] 2 3 ... 9
Morning All.

I've had a report that a new runtime error (Error: no openssl_applink) has appeared when compiling a NetTalk Server application using Clarion 10 build 12567.
The error appears to be caused by the following;

(from the release notes)
- AppBroker: Renamed ipds_libeay32.dll  to libeay32.dll and ipds_ssleay32.dll to ssleay32.dll
- moved AppBroker to use OpenSSL version 1.0.2k

As can be seen from the above notes the DLL's are now using their default names (a good thing, because it makes them easier to replace as OpenSSL updates) and they're using version 1.0.2.k (also a good thing.)

Unfortunately the LibSSL32.DLL is not included in the shipping set.

The error occurs in a NetTalk program because there is now a mix of versions (1.0.2k for the 2 mentioned above - and currently 1.0.2j for the LibSSL being shipped by NetTalk.)

There are a number of possible solutions;
a) SV should ideally ship a complete set of the OpenSSL DLL's - by shipping LibSSL as well as the other 2. This completely removes the possibility of 2 versions of OpenSSL being "mixed".  (logged as PTSS: 42457)

b) Delete libeay32.dll and ssleay32.dll from the \clarion\bin folder. (Appbroker will then use the ones in \accessory\bin). This is less ideal, but may be necessary for this build.


Web Server - Share Knowledge / MS Sql Recommended Driver Strings
« on: May 17, 2017, 10:14:43 PM »
A summary of recommendations for SQL Driver strings when used in a NetTalk Web Server context.

If you are using MsSql with your web server, and you have more than one user using the server, then you will likely run into the STMT Connection Busy error.

see here for a fuller explanation;

In our experience here we've found that turning MARS on does completely eliminate the error. We're using Ms SQL 2005, and Clarion 6.3.9058. You may have similar success with earlier builds of Clarion, we haven't back-checked to see exactly which build works the best.

The key issue though is "turning MARS on". Despite what the SV post above says, it does not appear to be automatic. In essence, the _first_ file opened in the database must have the driver setting


If you are using FM3 then the first file that connects is none of the ones in your dictionary, but rather the FM3 connection file. In order to set the driver string for that, you'll need a recent build of FM3.

You may also want to set the /ISOLATIONLEVEL to a specific value - do not just assume the default value is as documented in the Clarion Help. There are suggestions that it defaults to level 2, although the documentation suggests it defaults to 1.


this is a continuation of

>> I've looked at the jFiles class a little trying to improve performance and can't really tell what's making it slower

the key to improving performance is to use a Profiler to show where it is going slow. I'm using this;  -  Trying to do it by "eye" is a waste of time.

>> In itself the json is roughly a factor 1.2 to 1.5 slower than xml (for the tests I'v run) that's fine/acceptable. but when the requests come in randomly serving json becomes really troublesome. My production server will have to server even larger result sets and I can't hope that there will be no "collisions".

Clearly collisions will be happening so it needs to cope with that. I haven't managed to get back to testing yet, but there are a variety of approaches that can be taken. I've also got some suggestions for reducing memory usage, so that's good.

>> So I'm still looking for a way to produce and serve json fast Maybe a really stupid question: but is there a chance of producing JSON with the xFiles class (in the end it goes through the same structures and I can see "some" resemblence between xml and json <g>)?

some years back I looked into that - indeed there are some remnants of that in the xfiles.clw file, but it becomes somewhat limited quite quickly. It's possible that for edge cases there are approaches like that, but I would likely extend jFiles to handle edge cases rather than tweak xFiles at this point.

But there are a number of other options to try first before going down that road.


Web Server - Ask For Help / jFiles - List Arrays
« on: July 31, 2015, 10:17:28 AM »
start a new thread here Willie - the old thread is "blank" to me. (you'll need to repeat your last post.)

Web Server - Share Knowledge / Security alert : FREAK bug
« on: March 04, 2015, 06:35:21 AM »
Just a quick update for those paying attention to SSL errors;

A new bug called FREAK has been reported. It attacks servers that allow
EXPORT level ciphers for SSL. EXPORT ciphers are very weak (by design) but
some servers still offer them as a viable option when making an SSL


If you are using NetTalk 5.30 or later, and you haven't specifically changed
the .CiphersAllowed property, then this does not affect you.

Longer version;
The levels of SSL are discussed here;
Specifically the issue with FREAK is the CiphersAllowed property. NetTalk
has included !EXPORT (meaning EXPORT ciphers are explicitly not allowed) in
the default value of this property for a long time now - since at least
version 5.30.

<plug> So once again NetTalk users are safe because it's designed not to
rely on each programmer to get the security right. We default to secure, and
we often tweak the defaults to make things more and more secure. As long as
you stay up to date you benefit from that. </plug>

A good way to test your site to see if it is vulnerable is to use the online
service at

We'll likely chat about this a bit more during the User Group webinar on


Web Server - Share Knowledge / OpenSSL 1.0.1j DLL's
« on: October 21, 2014, 06:54:06 AM »
Hi All,

It's good to keep up to date. The OpenSSL 1.0.1j DLL's are attached.


[attachment deleted by admin]

Web Server - Share Knowledge / Web Client Error / SSL Email Client error
« on: October 21, 2014, 04:21:03 AM »
Hi All,

There have been several reports from WebClient object users who are suddenly getting this error in their programs;

Error Code: -53
Error Message: The requested connection could not be opened. The Open
command timed out or failed to connect.
The error number was -53 which means Open Timeout or Failure error. - [SSL Error = 16]

This occurs when the web server you are talking to will no longer accept SSLv3 connections, and require you to use TLSv1 (or later) connections.

Because of the POODLE bug many servers have indeed stopped accepting SSL 3 connections.

You can update your object by setting;

ThisWebClient.SSLMethod = NET:SSLMethodTLSv1

Alternatively you can change the default, as set in netsimp.clw so that all WebClient objects are affected. (The default has been changed for builds 8.29 and later.)

NetSimple.Init method
change the line
self.SSLMethod = NET:SSLMethodSSLv3
self.SSLMethod = NET:SSLMethodTLSv1

update : While it mostly manifested as a Webclient issue, this above issue can affect and program that comminucates with a server via SSL. In other words it might be email, or ftp, or whatever. The solution though is the same, since SSLMethod is a property of the NetSimple base class.

Bruce Johnson

Web Server - Ask For Help / Re: Best place to process a URL parameter
« on: October 07, 2014, 10:15:22 PM »
[ reposted here as the other thread is too long]

Hi Bruce

I have removed the code in 'NewSession' that related to the URL parameter.

The problem persisted and I did more testing.  The situation in the code now is:

The parameter (bparm) is not initialised
bparm is set via: p_web.StoreValue('bparm') in the ProcessLink Procedure
bparm is not altered in any other code

The assumption in the above code is that if the parameter exists then the session variable 'bparm' is stored via StoreValue and if it is not present then it is blank.  Another assumption is that if it was present at the start of a session then the session variable remains at the initial value even when the URL changes. 

Well, it looks to me as if this is not always the case.  When starting the session with ?bparm=bill I included the following in ProcessLink:

  stop('b4 store='&p_web.GSV('bparm'))
  p_web.StoreValue('bparm')    !save any URL parameter
  stop('after store='&p_web.GSV('bparm'))

The result is that frequently the first STOP displays 'bill' and the second displays blank.

I say 'frequently' because the ProcessLink procedure is executed a lot  and sometimes I correctly get bill/bill and sometimes bill/blank.  Sometimes I get bill/blank then blank/bill.

Now, once bill becomes blank my file path names get screwed up.

Of course, as noted before, if I execute without the parameter everything is ok because the pathname is being set thru a login procedure which is not dependent on the parameter.

It looks to me as if the problem is in StoreValue which sounds crazy I know but I cannot get any more granular in my investigation.

Your sage thought appreciated as always.


Pages: [1] 2 3 ... 9