I'm aware of LIMIT and OFFSET, available in both DB2's but for my requirements I need to use WHERE.
DB2/ZOS 12 supports ...
WHERE (WORKDEPT, EDLEVEL, JOB) > ('E11', 12, 'CLERK')
but apparently not DB2/400?
Please someone tell me I'm wrong.
References
DB2/ZOS https://www.ibm.com/support/knowledgecenter/en/SSEPEK_12.0.0/wnew/src/tpc/db2z_12_sqlpagination.html
DB2/400
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/sqlp/rbafymultiplewhere.htm
There are 3 completely different platforms for DB2
Db2 for z/OS
Db2 for IBM i
DB2 for Lunix, Unix, Windows (LUW)
Despite sharing the DB2 name, they are completely separate products with different code bases.
IBM does try to ensure compatibility, but that doesn't mean that every platform has the same capabilities or gets new features at the same time.
So no, Db2 for i doesn't currently support non-equal row-value-expressions in the WHERE. You'll have to go old school.
WHERE
(WORKDEPT = 'E11' and EDLEVEL = 12 and JOB > 'CLERK)
or (WORKDEPT = 'E11' and EDLEVEL > 12)
or (WORKDEPT > 'E11')
Related
We've just upgraded to z/OS V2.2 which comes with Java 8. We have a product that doesn't work with Java 8 and so we want to take Java 7 out of out z/OS V1.13 zone and put it into it's own zone.
I've done a BUILDMCS for Java 7, defined a new zone, added the necessary DD DEFS (as identified by the BUILDMCS) and received HJVB710 into the new zone. SMP built the relfiles using the datasets specified by the FROMDS parms of my MCS.
Thinking about APPLYing HJVB710 to my target zone and I realise that applying it will simply copy from the relfiles into my target libraries, which are the same libraries that the relfiles were built from and which already have all of the Java 7 elements in them.
Question - when using BUILDMCS to move an FMID from one SMP/E environment to another, should I specify a new set of target libraries? If not, should I then delete the FMID from the 'old' SMPE/E environment to prevent maintenance being applied to it, causing the target libraries to be updated and thus invalidating the information in the 'new' CSI?
I've gotten myself into a corner - I have really old dBase tables that contain 8.3 filenames that were obviously kept on an old msdos/windows system together with files.
All I have now are the files and the dBase (DBF file) - but the links that connect between rows in the db and the actual files are in 8.3 format. The files and dBase files have been copied over from the old windows machine to the linux machine.
for example the db will have a row containing:
{"fileid" : 1, "dosname" : "APPLE~1.JPG"},
{"fileid" : 2, "dosname" : "APPLE~2.JPG"}
and somewhere in the file directory i may have
"appletree.JPG"
and
"apple computer.JPG" .
how can I tell which is which? is there some kind of logic I can follow (like alphanumeric sorting to tell which is ~1 and which is ~2?)
Assuming that we are actually talking about 8.3 file names created by some Windows ... it isn't too hard.
Microsoft has a nice specification out there that exactly explains how those "longer" filenames are mapped to 8.3 "notation".
See here.
So you can sit down; and you should be able to come up with a mapping tool that well, maps the "long filenames" to their DB row 8.3 cousins.
Edit: as correctly pointed out, the above link is just a description, but not an exact algorithm for the required mapping - but maybe this algorithm does the trick for you!
All standards compliant applications in Linux store a desktop schema in /usr/share/applications/. In my particular use case, I have a WnckWindow data structure and I can get a pid from that. Using this pid, I can extract the command line from the proc.
Unfortunately, it seems that the proc command line entry does not match the desktop schema launch parameters. For example, the 'thunderbird' application is launched via /usr/bin/thunderbird but this is just a shell script which activates the real executable: /usr/lib/thunderbird-8.0/thunderbird-bin.
The real executable cannot be launched directly as it is dependent on the library paths configured in the /usr/bin/thunderbird script. Does anyone have any advice on how to match process id numbers to the appropriate desktop schema without getting caught by the issue I've described?, Thanks.
Ok, well, it appears that there's no nice way of solving this using the pid, however, it is relatively easy to match the Wnck windows class to application desktop schemas. The Wnck windows class needs to be preprocessed a little first to ensure that the filter works but it's pretty trivial stuff. Once you've got a good set of target strings, eg 'Thunderbird' or 'Google' + 'Chrome', you can use the system application menu API to zero in on a likely candidate, for example, by using garcon on Xfce.
My workplace has a .net application supplied to us by a postal service, it connects to an oracle database running on the same machine and is responsible for registering, storing and printing shipping labels.
Seeing as the database host etc. is configurable we asked the company if the application could be used over the network (simply copying it over to another machine resulted in "literal does not match format string" errors), all we were told is "it isn't possible". Not wanting to take no for an answer I poked around the exe with reflector.
Together with Oracle's v$sqlarea view I pinpointed the errors to a few date comparison functions, but I have no idea why the application was working in the first place on the original machine.
The original application uses queries similar to
SELECT * FROM shipping WHERE date = '2011/03/28' --error
easily fixed with something like
SELECT * FROM shipping WHERE to_char(date, 'yyyy/mm/dd') = '2011/03/28'
Why does the original application work without throwing any errors? The incorrect query pops up in the v$sqlarea view when the application is used on the original host, if I copy the query and run it manually using anything else it throws the error, if I run the application on any other machine it throws the error too, is there some setting in Oracle that is modifying queries on the fly, but only for queries originating from the local machine, while storing the original query in v$sqlarea?
This sounds like a regional settings difference between the two client machines, since formatting of dates will be dependent on the culture used to convert the date to a string in .NET, and unless the application specifies a culture, it will use the settings of the current logged on user running the application. This is obviously a problem if the database engine is expecting them in a certain format. This problem is less likely to arise with parametrized queries, where the date parameters are passed separate from the query and as a date datatype instead of a string.
If you work with dates, you must avoid String.Format based query generation. Use parametrized selects and parameters to set those values.
OracleCommand cmd = new OracleCommand("SELECT * FROM shipping WHERE date = :dataParam", connection);
var param = cmd.Parameters.Add("date", OracleDbType.Date);
param.Value = DateTime.Now;
It worked, because the format was matching the datetime settings on the developer machine and on the target database.
In other words: the issue is connected to an incorrect date time format you are trying to provide.
This could be because of regional settings on the server. Please check that the new server is configured for the same Locale (EN-GB, EN-US, or whatever the original server is configured to use).
I tried to trace ODBC function calls from my program working on Linux. This program dynamically links ODBC manager and then connect to database and fetch some data.
I can trace ODBC calls with unixODBC by adding to odbcinst.ini:
[ODBC]
Trace=yes
TraceFile=/tmp/sql.log
This method is documented by IBM: Collecting data for an ODBC Problem
But when I change manager from unixODBC to Informix's own manager (libifdmr.so), the trace file is not created. Anybody successfully obtained ODBC trace from Informix manager (and driver) on Linux?
Client version: CSDK 3.50UC3
I hope that it is not a bug and something is wrong with my config.
As for unixODBC: I cannot use unixODBC in multithreaded app. I use connection pool and my app segfaulted when disconnection was from another thread than connection. It is also much slower in multithreaded app.
If you run:
strings $INFORMIXDIR/lib/cli/libifdmr.so | grep _OdbcSetTrace
do you get to see any references. If not, then the library is without the support functions. If you do see that, the mechanism outlined should work. If it doesn't, you probably have a reportable bug.
What level are you trying to trace the issues? And, since unixODBC works, why not use the driver manager that does work?
I've taken the example distsel.c from $INFORMIXDIR/demo/cli and compiled it on Solaris 10 using CSDK 3.50.FC3. I got it to the point where the connection succeeds, but the table 'item' is missing in the database I'm using, so the program stops SQLExecDirect(). When I run it under 'truss' (equivalent of 'strace' on Linux), then I see no evidence of the code even trying to open the trace file.
I compiled using:
gcc -I$INFORMIXDIR/incl/cli distsel.c -DNO_WIN32 \
-L$INFORMIXDIR/lib/cli -lifdmr -lifcli -o distsel
I used the following .odbc.ini file:
;
; odbc.ini
;
[ODBC Data Sources]
odbc_demo = IDS 11.50.FC3 stores on black
[ODBC]
Trace = yes
TraceFile = /tmp/odbc.trace
[odbc_demo]
Driver = /usr/informix/11.50.FC1/lib/cli/libifcli.so
Description = IBM Informix CLI 3.50
Server = black_19
FetchBufferSize = 99
UserName = jleffler
Password = XXXXXXXX
Database = stores
ServerOptions =
ConnectOptions =
Options =
ReadOnly = no
And this one:
;
; odbc.ini
;
[ODBC Data Sources]
odbc_demo = IDS 11.50.FC3 stores on black
[odbc_demo]
Driver = /usr/informix/11.50.FC1/lib/cli/libifcli.so
Description = IBM Informix CLI 3.50
Server = black_19
FetchBufferSize = 99
UserName = jleffler
Password = XXXXXXXX
Database = stores
ServerOptions =
ConnectOptions =
Options =
ReadOnly = no
Trace = yes
TraceFile = /tmp/odbc.trace
Consequently, I believe you have found a bug. I'm not sure whether the bug is in the FAQ you referenced or in the product - I'm inclined to think the latter. You should report the issue to IBM Technical Support. (I've not checked the Informix CLI (ODBC) manual; it might be worth checking that before trying to file a product bug; if the manual indicates that Trace doesn't work, and perhaps if it doesn't indicate that it does work, then there is a bug in the FAQ page you listed.)
If you are looking to see the SQL data, the SQLIDEBUG part of the FAQ works:
SQLIDEBUG=2:distsel ./distsel
That generated a file distsel_6004_0_102d40 for me - it will be different for you. You can then use the 'sqliprint' utility to see the data flowing between client and server.
If you cannot find 'sqliprint', get back to me.
I got ODBC trace with those settings in my odbc.ini:
[ODBC]
TRACE=1
TRACEFILE=/tmp/odbc_trace.txt
TRACEDLL=idmrs09a.so
I copied them from IBM Informix ODBC Driver Programmer’s Manual Version 3.50.
So other IBM documents seems not valid while those settings are in odbc.ini instead of odbcinst.ini and you must set TRACEDLL which was not mentioned in "Collecting data for an ODBC Problem" document.
UPDATE:
It seems IBM changed documentation: there is info on TRACEDLL, but odbcinst.ini remained.