I prefer readable code. Slapping gibberish onto a perfectly good name does not improve readability.
In any event, as Stefan points out, one of the really nice things about the delimited list approach is that it is easily reversible. Use ENTRY() to get the month name or LOOKUP() to get the...
One more thing: "hungarian notation" (the practice of pre-pending gibberish in front of perfectly good identifer names) is an abomination and an affront to readability. Even Microsoft has seen the light and deprecated the practice.
Queries do not display anything.
A browse displays the records in the result set of its associated query.
You cannot change what has been selected by the query or what order the records are in after the query has been opened. Once you open it all of that is fixed - it is not changeable.
What is your evidence for having found a "corrupt record"?
Depending on what you have actually found you may, or may not, have a good reason to rebuild one or more indexes.
It is unlikely that a single "corrupt record" is responsible for the sort of performance difference that you describe and...
I'm sorry but I have no idea what you are asking.
Your question seems to have something to do with displaying data. Apparently there is a two-step process involved where you want to modify the first result set somehow based on some attribute of the initial query. But I see no example code...
The code above is, of course, absolutely dreadful from a performance point of view. It will read the entire database. Multiple times. That is no big deal for sports2000 but it is unlikely to be a good idea for any real production database.
"Now" it is too slow? Was it faster before? If it was faster before "now" then the main question should be "what has changed"?
If it has always been too slow then an investigation of your configuration and potential tuning options will probably be necessary. As Cringer mentions ProTop is an...
mpro sports2000 -p fe.p
When prompted type "lift" or whatever.
define variable searchFor as character no-undo format "x(40)".
define variable recordsFound as integer no-undo.
for each _file no-lock
where _file._file-num > 0
Maybe you should step back and explain this in more depth with an example that uses an actual TT definition and some real field names?
At this moment it seems like a ridiculous thing to be trying to do.
From: Chapter 4: Configuring PuTTY | PuTTY User Manual (putty-0.68-manual)
4.3.10 REMOTE-CONTROLLED PRINTING
A lot of VT100-compatible terminals support printing under control of the remote server. PuTTY supports this feature as well, but it is turned off by default.
Why on Earth would you ever use bulk load?
But, to answer your question, no.
At least not if you are thinking in terms of "proutil dbname -H hostname -S port ..." sorts of commands. Proutil does not support that.
The bulkload command needs to *run* in the context of the server being loaded...
In this sort of scenario you just go ahead and FIND NEXT ... NO-ERROR. If nothing is available you were on the last record (or the first if you were doing FIND PREV...) If you do it again then you "wrap around" to the FIRST. If you want you could do an invisible wrap-around by just doing a...
Something like this should do the trick:
define variable fName as character no-undo format "x(60)".
input through value( 'find /home/sk -name "mydoc.pdf" -print' ).
import unformatted fName.
Presumably you need to use "find" because the file is somewhere in...
That depends. If "use" means "compile" (on the server without a compiler license) then no. If "use" means run r-code that was created by compiling them at some point on a server that has a development system on it then yes.
General query construction advice: Start with positive statements about equality. Try to find ways to say that a field *equals* a value rather than expressing exceptions and filters.
The more equality matches you can specify the better your query will perform.
For instance, it is *much*...
In addition to the issues with CAN-DO pointed out in the link above it is very important to note that because CAN-DO is a *security* function it is *always* evaluated on the client. So when you use it in a WHERE clause you not only create a TABLE-SCAN, you also force all of the records to be...