I am running sphinx on a 32 bit machine and want to get the sql_attr_bigint to work.
Can this be done?
Should it work by default?
Do I have to re-compile and make any changes at compile time?
What effect will it have on performance?
My table id fits in 32-bits. I just need this with one attribute and it must be 64 bits.
Could the problem be in PHP?
the problem was in PHP. When I assigned the value from the result array to a variable PHP messed up the value. Sphinx is working fine with bigints on a 32-bit comp.
This can still work on PHP as sphinx returns attribute values as strings in the results array ( regardless of how they were stored in the index). So I can just use the string value in the PHP code.
Related
When some time ago I had developed a script to query network interfaces via snmpwalk and IF-MIB::ifDescr the output format was like STRING: eth0.
The OS was SLES11 using net-snmp (it still works in SLES12 using net-snmp-5.7.3).
However on a different OS (still Linux) the interface strings are represented as STRING: "port1" (note the surrounding double-quotes).
Now the question is: Who is responsible for the extra double quotes? A different version of net-snmp, or a different SNMP agent? Or is one of the results incorrectly implemented in the agent?
As far as I understand SNMP the double quotes are not necessary for the protocol as strings are always transmitted with their length.
While it would be unusual (and undesirable) for an SNMP Agent to provide a quoted string in response to a query for ifDescr (or for anything else!) as they are indeed not part of the contract of a string at that level, the SNMP world is rife with oddities and variations and specification deviations, so this is not something you can assume will never happen.
Meanwhile, the format of the command-line output of a tool like Net-SNMP is effectively arbitrary: the developers can choose whether or not to quote strings, and as long as they document their choice, the end result is the same. So you cannot make any assumptions here either.
You should examine the actual data. You can do this by sniffing the SNMP packets with a tool like tcpdump and loading them into a UI like Wireshark (previously Ethereal). Then you can observe the actual contents of the datagram without the Net-SNMP formatting. If it contains quotes, it's the agent's fault; if it doesn't, the app is adding them for display.
(There's probably a Net-SNMP flag to make it display the bytes, in hex form, making up the string, which would be an easier way to gather this evidence if I remembered what the flag was.)
As an editorial note, if you'd told us what the "different" Linux OS actually was, and what version of Net-SNMP you were using on it, we could have confirmed (or ruled out) option two for you.
(For what it's worth, I'm not aware of any Net-SNMP change that added or removed quotation marks from the command-line output, so this is probably an oddity of the agent on that "different" system.)
My output (csv/json) from my newly-created program (using .NET framework 4.6) need to be converted to a IBM-1027-codepage-binary-file (to be imported to Japanese client's IBM mainframe),
I've search the internet and know that Microsoft doesn't have equivalent to IBM-1027 code page.
So how could I output a IBM-1027-codepage-binary-file if I have an UTF-8 CSV/json file in my hand?
I'm asking around for other solutions, but for now, I think I'm going to have to suggest you do the conversion manually; I assume whichever language you're using allows you to do a hex conversion, at worst. For mainframes, the codepage is usually implicit in the dataset, it isn't something that is included in the file header.
So, what you can do is build a conversion table, from https://www.ibm.com/support/knowledgecenter/en/SSEQ5Y_5.9.0/com.ibm.pcomm.doc/reference/html/hcp_reference26.htm. Grab a character from your json/csv file, convert to the appropriate hex digits, and write those hex digits to a file. Repeat until EOF. (Note to actually write the hex data, not the ascii representation of the hex data.) Make sure that when the client transfers the file to their system, they perform a binary transfer.
If you wanted to get more complicated than that, you could look at enhancing/overriding part of the converter to CP500, which does exist on Microsoft Windows. One of the design points for EBCDIC was to make doing character conversions as simple as possible, so many of the CP500 characters hex representations are the same as the CP1027, with the exception of the Kanji characters.
This is a separate answer, from a colleague; I don't have the ability to validate it, I'm afraid.
transfer the file to the host in raw mode, just tag it as ccsid 1208
(edited)
for uss export _BPXK_AUTOCVT=ALL
oedit/obrowse handles it automatically.
I'm working on a project for school.
The assignment is as follows:
Implement a sorting algorithm of your choosing in assembly (we are using the GNU Assembler). The input is a text-file with a series of numbers separated by newline.
I'm then trying to implement insertion sort.
I have already opened and read the file and i'm able to print the content to terminal.
My problem is now how to split each number from the file in order to compare and sort them.
I believe google is glowing at the moment due to my effort to find and answer (maybe I don't know what I need to type or where to look).
I have tried to get each character from the string, which i'm able to do BUT I don't know to put them together again as integers (we only have integers).
If anybody could help with some keywords to search for it would be much appreciated.
I am maintaining a project where data has to be shared between windows and linux machines.
The program has been developed in DELPHI (Windows) in 2003 - so there is a lot of legacy data files that must be (at least probably) read by both systems in the future.
I have ported the programm to Lazarus and it runs on Linux quite well.
But the data (in a proprietary format) has stored strings as general ascii-characters from #0-#255. Reading the data on a linux machine leads to a lot of '?'-Symbols instead of 'ñ,äöüß...' etc.
What I tried to solve the problem:
1.) I read the data on a windows machine - as usual.
2.) I saved the data with a modified version, that will encode all strings with URLEncode()
on saving.
3.) I also modified the routine reading the data with URLDecode
4.) I saved the data with the modified version.
5.) I compiled the modiefied version on linux and copied the data from the windows machine.
6.) I opened the data in question ... and got questionmarks (?) instead of 'ñ,äöüß...' etc.
Well, the actual question is: How to share the data maintained by both systems and preserving those characters when editing the data (on both sides)?
Thanks in advance
8bit Ansi values between 128-255 are charset-specific. Whatever charset is used to save the data on Windows (assuming you are relying on Windows default encoding, which is dependent on the user's locale), you have to use that same charset when loading the data on Linux, and vice versa. There are dozens, if not hundreds, of charsets used in the world, which makes portability of Ansi data difficult. This is exactly the kind of problem that Unicode was designed to address. You are best off saving your data in a portable charset, such as UTF-8, and then perform conversions to/from the system charset when loading/saving the data.
Consider using UTF-8 for all your text storage.
Or, if you are sure that your data will always have the same code page, you can use conversion from the original Windows code page to UTF-8, which is the default Linux/Lazarus encoding.
You should better not rely on any proprietary binary layout for your application file format, if you want it to be cross-platform. You just discovered the character encoding problem, but you have potentially other issues, like binary endianess. SQLite3 is a very good application file format. It is fast, reliable, cross-platform, stable and atomic.
Note that Lazarus always expects utf8 strings for GUI. So even on Windows this probably wouldn't work without proper utf8 sanitation
I have two projects, one in Windows and another one in Linux. I use the same database for both (oracle 10g),I have got an input file which consists of text that includes special characters (ÁTUL ÁD).
the program logic is like this: read input file data to database, on windows the data (including the special characters) is displayed correct, on Linux the special characters display other characters. As I already said, I use same database for both of them, could you give me some help?
The program is complex, it uses the Spring Batch Framework. Maybe the encoding causes the problem, but I have no idea how to solve it. I am using Linux for the first time.
Thanks in advance.
I find one solution which works for me is that you have to use UTF-8 encoding. All for Windows,Linux and Database.