×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
I'm contemplating on the most efficient, and least error-prone way to handle database reads with multiple key fields. Goals are: Avoid copying data, use pointers to existing variables whenever possible. Avoid hard coding field sizes. These should be derived at compile time, if possible. If not, they should be derived at most once in the code flow.
Because we're talking CL environment here, I assume all strings to be fixed-length, no zero-termination. Correct?
I need to gather the necessary data for the desired key values and copy those to the proper relative positions reflecting the key field positions within one big buffer for _Rreadk. Is this how multiple key fields work? I haven't found examples. Not in the net, not in the documentation PDFs.
One can include "key" as flag when referring to external defined files with #pragma mapinc. This results in a "_Packed struct" being defined for all key fields of the file in question. I was trying to typecast a char pointer to a variable of this type "_Packed struct …", but the compiler disallows this.
At the moment, I'm thinking about using hard coded sizeof() calls for each key field, to get a sum for malloc()ing the mentioned big _Rreadk key buffer. And defining individual character pointer variables using pointer arithmetic with the derived field lengths to the proper key field positions within this big buffer.
Did you use multiple-key PFs with _Rreadk? How did you handle the proper assembly of the buffer with the key-values? How did you automatically deduct the proper size of the (key) fields for assembly of that one big buffer?
What's your opinion?
:wq! PoC
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.