virtual table file name is not valid in search.

Ragav86 · New User Joined: 27 Jan 2010 Posts: 37 Location: chennai

Hi can any one let me know why i am getting the following error while reading the virtual table.
my requirement is to capture all the records from the file to table(records with '*' in first column need to be skipped) and need to perform a search..

PeterHolland · Posted: Tue Feb 21, 2012 3:02 pm

Try FILE CBNOT TABLE 2000 VIRTUAL F(80) RETAIN

Ragav86 · New User Joined: 27 Jan 2010 Posts: 37 Location: chennai

no still i am getting the same error..

Ragav86 · New User Joined: 27 Jan 2010 Posts: 37 Location: chennai

virtual table is possible in Eazytrieve?
is there any other way?

Bill Woodger · Posted: Tue Feb 21, 2012 5:12 pm

Do the VIRTUAL first, TABLE after. Forget RETAIN unless you are using reading the table/file in more than one JOB/SORT.

PeterHolland · Posted: Tue Feb 21, 2012 5:17 pm

Bill, sequence of the parameters is of no importance. Retain is necessary cause the TS is doing a sort first, and using the table in the next EZT job.

Bill Woodger · Posted: Tue Feb 21, 2012 5:30 pm

Hi Peter,

I always coded in that order, never had a problem :-)

The RETAIN is only relevant for reading a file. If it is the output of a SORT, not a probllem, which is logical, there'd be no sense in creating the file to be not able to read it.

I'm just looking at the code. Isn't that weird? ARG and DESC are on a different file, the input to the SORT, and are used for selection. The TABLE doesn't have ARG or DESC. Methinks that'll be the problem.

EDIT: Just noticed the Copy. No idea if this will do what you think it will do. ARG and DESC on a TABLE are sort of special things. It seems you have definied them elsewhere just to be able to include them with the copy? Try not doing that.

PeterHolland · Posted: Tue Feb 21, 2012 5:35 pm

Hey Bill, the table has a copy statement pointing to the unsorted table.
I never had problems with table parameters in any sequence.
But for tables targetted by sort i always used FB(x y).

Bill Woodger · Posted: Tue Feb 21, 2012 5:49 pm

Hi Peter,

I certainly have never tried to COPY a file for a table (or anything, for that matter, always used macros).

I'm accepting that if you say the order is unimportant, it is unimportant. The RETAIN is unimportant. Without specifiying a length for the output, the SORT willl take it from the input.

I can't see anything "genuinely" wrong (although I'm being in and out very quickly today), so for me I'd concentrate on the ARG/DESC thing. Something doesn't work :-)

I'm assuming from TS's comment they tried the RETAIN anyway. Perhaps they didn't, but I do think that that is not the problem. It is an odd one.

PeterHolland · Posted: Tue Feb 21, 2012 6:21 pm

Try this :

Bill Woodger · Posted: Tue Feb 21, 2012 7:20 pm

I'd be surprised as all heck if that didn't work out of the box, Peter.

Ragav86,

If you want to humour me, once you have Peter's code in place, can you then try

Ragav86 · New User Joined: 27 Jan 2010 Posts: 37 Location: chennai

Hi peter & Bill
Thanks for your reply. both codes are working fine..

Bill Woodger · Posted: Tue Feb 21, 2012 8:32 pm

Thanks for letting us know.

If you want to try a little "problem determination" before contacting CA, you could try your original but without the COPY for the TABLE file, just define the ARG and DESC.

If that fails as well, it is because confusion has been caused (to the compiler) by ARG and DESC on a non-TABLE file.

If it works, then the problem is with the COPY either in itself, or with non-TABLE to TABLE. So try with two TABLEs (create another TABLE file with another SORT of your original input, and try the COPY on that).

Then you will have something concrete for CA. Let us know if you can narrow it down please, it may assist future readers.

Ragav86 · New User Joined: 27 Jan 2010 Posts: 37 Location: chennai

sure bill i will let you know soon...

PeterHolland · Posted: Tue Feb 21, 2012 11:04 pm

Bill Woodger · Posted: Tue Feb 21, 2012 11:23 pm

Why, Peter? It is your code, working as we expected it would. Plus your code with my suggestion for the file definition for the TABLE.

I've learned something today, so thankyou for that.

For the next topic with a FILE I'll know not to query the order. I used macros for file definitions, so coded in the macro in the order of the manual. Even though I could have then invoked the macro with the parameters in a different order, I never did. I like them all to look the same. Never realised the order I'd put them in the macro was irrelevant :-) Thanks.

PeterHolland · Posted: Tue Feb 21, 2012 11:39 pm

Bill, I have the feeling that the TS fooled both of us. Probably he didnt show the real stuff. Well, whatever it was nice talking to you. Take care.

Bill Woodger · Posted: Wed Feb 22, 2012 3:35 am

Peter, igualmente. I'm hoping that what TS showed us was a cut-down version of an actual program. I think there is something of the "language barrier" problem, and that TS is a person of few words. I certainly hope we've not been fooled.

Ragav86, I just noticed you don't test that the search was successful. You'll need to do that, else you'll just get whatever value was last lying around from the previous successful search, if any, as the DESC is only move if the search was successful.

IF CBNOT
it was found in the table
ELSE
it was not
END-IF