We have Informix running on our Solaris server and under /usr/informix/bin there are several executables, such as 'dbaccess' and 'isql'.
Each of them produce different version information when typing 'isql -V' for example.
How do you identify the exact version of the SE running?
Output:
'esql -V'
INFORMIX-ESQL Version 6.00.UH1
'isql -V'
INFORMIX-SQL Version 6.03.UC1
'dbaccess -V'
DB-Access Version 7.13.UC1
Then in /usr/informix/release directory there is a file named "SE_7.1". So is it accurate to say that the version of Informix SE we are running is 7.13?
Most likely, you are running SE 7.13; the definitive answer is obtained from:
$INFORMIXDIR/lib/sqlexec -V
However, DB-Access is distributed with SE and would give the correct version unless there was at some time a copy of Informix Dynamic Server (or Informix OnLine Dynamic Server as it would have been labelled back then).
All the software is seriously archaic. Version 6.03 of ISQL was released circa 1996; SE 7.13 would be a little earlier, if anything. The ESQL/C was probably released in 1995; 6.00.UE1 was released in 1994 or 1995, and the UH1 release would have been a little later (a couple of fix packs). Formally, none of the software is guaranteed Y2K-compliant; you'd be using SE 7.24 and ISQL 6.05 (or possibly 7.20) and ESQL/C 7.24 as minimum version numbers. However, the problems with SE and Y2K were far less serious than with other versions. The main issue is that the code will add 1900 to 2-digit years, not 2000.
The current version of SE is 7.26; the current version of ISQL is 7.50; the current version of ESQL/C is (don't ask) 3.50.
Just to add to Jonathan's typically exhaustive answer, DB-Access is bundled with the engine, but isql and esql are both separate products. That's why you're getting different answers to the version number request. They're all correct answers to different questions ;-)
Related
I use TOSVersion.ToString function (uses SysUtils) to detect Windows version. However this is what I get in Windows11:
Windows 10 (Version 10.0, Build 21996, 64-bit Edition)
Is there any reliable way to detect Windows 11? I'm using Delphi 10.3.3.
UPDATE: Windows 11 is officially released and I tried again.
Here is what I get:
Windows 10 (Version 10.0, Build 22000, 64-bit Edition)
As Remy pointed out: using the WinAPI you risk of being in some compatibility mode, resulting in getting a version reported that is lower than the actual.
One alternative is to check the file version of expected files, i.e.
%windir%\system32\ntoskrnl.exe or
%windir%\explorer.exe
using GetFileVersionInfo() and VerQueryValue() - the HiWord(dwFileVersionLS)
should be 22000 or higher (according to Windows NT build/release number).
Another is to look in the Registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ at the text values CurrentBuild and CurrentBuildNumber, checking if the highest of both is 22000 or higher.
David already wrote a detailled answer in Checking Windows version on W10 with even more alternatives, although concentrating on the high/low version numbers, not the build. But WMI might help.
(This only works in retrospective with confirmed knowledge.) Check which API exports are available: the idea is that specific functions were introduced with specific Windows releases/versions, so if importing fails for one you know you're on a version below. An outdated example and an outdated list of minimum versions per function will give you an idea. Now you "only" have to find out which new functions are introduced with Windows 11.
Those are all not bulletproof, but you could combine them and then draw conclusions. And after all that you can still try your approach to parse texts instead of relying on numbers only. It also shows how easily you can manipulate your system into reporting different versions as per which method is used.
Official major version number for Windows 11 is 10.
The official build number for the public preview of Windows 11 is
10.0.22000.168
Earlier builds:
10.0.22000.71
10.0.22000.65
10.0.22000.51
Microsoft Windows 11 FAQ
If you want to detect Preview versions, earliest build number was 10.0.22000.51 Windows 11 version history
TOSVersion relies on some hard coded names and logic to return OS name. You will have to implement your own detection, copy and modify TOSVersion record or make wrapper around it, where you can use existing logic for older versions and implement check based on Windows 11 build number to detect Windows 11.
For other general issues and approaches in detecting OS version you can refer to AmigoJack's answer
Except the very weak, atleast for me, solution of considering Windows 10 builds greater than 22000, such as Windows 11, the only solution I found which is actually working is the WMIs Win32_OperatingSystem class - Caption property.
On my dev Win10 machine, it gives the following string: Microsoft Windows 10 Pro.
On my another dev machine, with Win11 installed, the same function gives: Microsoft Windows 11 Pro.
The difference is in string values - "10" vs "11"- but this is at least something far better than the "build greater than" solution.
C# and C++ work well.
The simplest way is to get the version of Kernel32.dll and if Major Version is 10 and Build Version is >= 22000 then you have Windows 11.
See my code here: How can I find the Windows product name in Windows 11?
I'm pretty new to Informix and I'm trying to run a screen with sperform, but it's just seg faulting when I try to query. So far I have:
installed Ubuntu server 12 (64bit)
installed the Dev suite and runtime 7.50
installed the Informix engine 12.10
verified it was all up and running; can connect with dbaccess
created an example database & table and inserted a couple rows
generated a form using isql from the table
ran the generated form with sperform
As soon as I attempt to query with the form, I get a "Segmentation fault (core dumped)" and it exits. Can anyone help me understand why? Isn't this as basic as it gets?
Preliminary answer
Yes; that is as basic as it gets. No; it should not crash. There are essentially no circumstances under which that sequence should crash. You should probably file a bug report with IBM.
The only thing that might conceivably be an issue is that ISQL may have been built with an older version of the CSDK than the server installs and there may be an unexpected incompatibility. It should work, but occasionally flaws creep in. If you want to explore how to prove this possibility, say so. It is a little fiddly, but may get you up and running while the problem is resolved formally.
Extended answer
YES! I'd love to try to fix this.
The first step, it seems to me, is to see whether ISQL (Informix SQL) runs correctly when installed on its own — rather than when mixed with the Informix server code. It should work in both environments, but it is possible that the new server code has changed something that is causing the older tools code to break.
So, reinstall Informix SQL (and the other dev tools if you want, but you could save those until you've got a POC with just ISQL) into a new directory. Let's suppose your server is installed in /opt/informix; you could install your tools in /opt/isql instead. (No need to uninstall the tools from under /opt/informix yet.)
Copy the server sqlhosts file (from /opt/informix/etc/sqlhosts) to the new /opt/isql/etc/sqlhosts.
Change INFORMIXDIR=/opt/isql.
Add the new value to the front of your path (PATH=$INFORMIXDIR/bin:$PATH).
Worry about the setting of LD_LIBRARY_PATH — you want to pick up libraries from under /opt/isql/lib in preference to those under /opt/informix/lib.
Leave INFORMIXSERVER unchanged; you'll still be talking to the same database server.
You should now try to (re)generate the form file and run it. With a small modicum of luck, it will work now.
OK, that works! Don't know if that's a good thing or not, but we're going to try to get that change into production.
It gets you going; that's good. It's also a relief to me that the fundamentals of the QA process for the tools release didn't break down. The product works when run in the environment it was developed for.
It's a nuisance that a later release of the server changed something so that the older build of the tools no longer works with the newer server. It is supposed to be OK. However, running with separate INFORMIXDIR values for tools and server is not unheard of. If the server was on a separate machine, the segregation would be inevitable — the tools would use a separate INFORMIXDIR from the one used by the server (ignoring NFS file systems, etc)
Is it possible that there's some aspect to my steps that cause something to be overwritten?
No. The classic 'Rule of TEN (Tools, Engine, Network)' — install tools before the server (before the network-enabled version of the server) more or less applies and is what you did. The separate network-enabled version of the server ceased to be relevant about 20 years ago, but tools before engine (the 'Rule of TE' just doesn't cut it) is normally correct.
Since the workaround works, we need to look ahead a bit: what does it mean for you?
You have a solution that will work pro tem.
You will need to be careful with environment setting when you run programs.
Programs using the tools (Informix 4GL, Informix SQL) will be run with INFORMIXDIR=/opt/isql and consequential environment settings.
Programs installed by the server (DB-Export, DB-Import, ON-Stat, etc) will be run with INFORMIXDIR=/opt/informix and consequential environment settings.
If you wish, you can set up scripts in /opt/isql/bin for the programs from /opt/informix/bin that you want developers or users to use.
The scripts in /opt/isql/bin will set the environment correctly for the server and then exec the server program.
The scripts in /opt/informix/bin will similarly set the environment correctly for the tools and then exec the tools program.
In each directory, assuming you're careful, you have a single script that actually sets the environment and runs the other program; the program names are simply (symbolic?) links to the master script.
You have two separate master scripts — one to set the server environment, one to set the tools environment.
You should report the problem to IBM (Informix) Technical Support. You can outline what you've had to do to work around the problem. The fact that you have a workaround will lower the urgency, but it is still a problem that should, ideally, be fixed. (The world isn't ideal though, just in case you hadn't noticed; it may take time for the fix to be delivered.)
Does anyone recall if there ever was a Turbo or Online 5.0 version for MS-DOS, or was 4.10 the last released DOS version?.. I do know that the 4.10 client was able to link to Online 5.01 and 6.0 severs on Unix, via I-NET, but unable to leverage SP's and triggers.
I'm trying to locate an Online DOS version, if one exists, so I can leverage VARCHAR's, BLOB's and other Online features not available in SE.
There was never an Informix OnLine 5.0 for MS-DOS, AFAICR, nor any later version of Informix products. Development for MS-DOS stopped before that.
You would not be able to obtain it very easily even if I'm wrong and it once existed (25 years or so ago). It would only be obtainable on the second-hand market.
I would like to know if anyone is using Neo4J 1.8.x Embedded with Sun JDK 7? IF so, have you hit any issues and what are they?
Let me also clarify, I'm not looking to build the Neo4J source code - only run Neo4j 1.8.1 Embedded on Sun Java 7.
I know that Neo4j 1.9 is the first version that will support Java 7, but if Neo 1.8.1 runs on Sun JDK 7 without any problems, we will be considering deploying with that.
There are a number of benefits (i.e. security, etc.) to going with Java 7, but if there are compatibility issues with Neo 1.8.1, we'd like to find out.
Thanks,
Bob
Java 7 has changed the built in sorting algorithm. The new sorting algorithm (TimSort) is more sensitive to concurrent modification. Where the sorting algorithm in Java 6 and earlier would just produce a result that wasn't perfectly sorted in the face of concurrent modification, TimSort will throw an exception.
Neo4j uses these sort() methods in its page cache.
These exceptions means that Neo4j will crash unexpectedly when running with multiple threads on Java 7.
The Neo Technology team are addressing this issue for Neo4j 1.9.
Can an ISQL Perform screen connect with IDS or SE installed on a Windows platform?.. If so, which versions of isql client are capable and supported?..
ISQL has not been ported to Windows for quite some time (not this millennium, I believe), though it is still ported to Unix systems routinely. Therefore, you are looking at 'old' versions of ISQL; I suspect that there is no supported version of ISQL for Windows.
Yes, ISQL can connect to either IDS or SE running on Windows. There should be no problems unless you try to run Perform against a fragmented table (necessarily in IDS) created without the WITH ROWIDS clause.