When SELECT doesn't select!!

[tacs]

I think this could be a good one. I have certainly never seen it before so if anyone has could they help please.

First of all, I am looking at someone elses code and so that won't help. This is a form with a grid on it which, when double clicked, should go off, create a readwrite cursor using a sql statement, select the cursor add some data to it and then go off and run a report. I have also seen this here on another form as well, but I'm sure this will do as a starter for ten.

Anyway. The sql certainly creates the cursor with the desired records in it so that's fine.

The form just doesn't seem to select anything, either this cursor or an actual table and SELECT() always returns 1.

SELECT tablename doesn't work, neither does selecting the workarea you get by nSEL=SELECT(tablename) and then using SELECT(nSel).

I have thought about the environmernt and ASESSIONS() tells me there is only 1 session running so it should be visible, you CAN select it if you stop the form and run the command in the command window. If I step it through the debugger it works perfectly so I am a bit confused now. Any help will be gratefully received. Thanks.

 

[Olaf Doschke]

so your problem is, the cform selects data and you can't see a cursor alias? Show the datasession window and see if there is an alias called "Query" or even just a single letter. Try ? ALIAS() at the command window.

Besides that I'm a little amused about the fact, that you think code from someone else won't help us figure out the problem. If someone posts his own code, he may have a better understanding of what it's suposed to do, but that's the only difference. We're used to look at other peoples code and find the problems in them

Bye, Olaf.

 

[tacs]

Thanks Olaf. I just meant that as I didn't create the form I may not be aware of some setting that it may make. So I may well have missed something, hopefully something simple that makes everyone go .......DUH!! Not trying to disown it...exactly.

I've looked at the datasession and there are 16 tables and cursors in it, but none of them can be selected in code.

I have put various traps into it, for example:

IF UPPER(ALIAS())=="TABLENAME"
messagebox("Got It")
ENDIF

This is happily accepted as the currently selected alias(), but it's not if you check in the debugger and if I try to index the cursor it fails to recognise the field used.

I know it sounds crazy, but I just can't think what else to look for. Thanks again.

 

[tacs]

Sorry, I meant to say that you can select it in the command window.

 

[Mike Lewis]

Tacs,

Not sure if this will help, but when you double-click on a grid, I would expect the work area to be the one containing the cursor that populates the grid. This won't be the same as the one that you are creating in your SQL SELECT.

Having used SQL SELECT to create a new cursor, you need to SELECT the cursor specified in the INTO CURSOR clause, not the base table. In other words, if your SELECT is:

SELECT * FROM MyTable INTO CURSOR csrNew

you need to SELECT csrNew not MyTable. I'm sure you already knew that, but it wasn't obvious from your question.

Also, it's not obvious whether the cursor in question (csrNew in this example) is one of the 16 that are visible in the data session window. That's the first thing I would check.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[tacs]

Thanks Mike.

Yes, the csrNew has been selected in the code, I have tried several times, and yes I can see it as one of the 16 in the data session.

It's just strange, none of the tables or cursors in the datasession can be selected. The code runs through, but seems to completely ignore the SELECT command.

 

[Olaf Doschke]

Which SELECT command is ignored?

do SELECT aliasname in code, and SET STEP ON right afterward. Then the alias "aliasname" will be selected.

I wonder how you debug. If you start the form from the command window and while the form runs, you can still do commands in the command window, that means the form is nonmodal. That's fine. But the form may be in another datasession than the command window is. If you set step on in code within the form you'll have a break within the form's datasession. Now take a look at the datasession window again and see what you got there.

Bye, Olaf.

 

[tacs]

Thanks Olaf.

First of all the form was modeless, but didn't need to be so just in case .... I made it modal, but that didn't make any difference. I have put SET STEP ON immediately after saying SELECT csrNew and run the form. As expected it stops on the vey next line and in the debugger watch window I am watching ALIAS() which tells me it's an actual table called SALESORDERS.

I did consider the fact the both the debugger and the command window could operate independently so that they can see everything, but I'm not sure how else to debug this.

I have tried putting messageboxes about the code, and these seem to confirm what I am being told by the debugger about the currently selected table.

 

[tacs]

Also, I have tried running this both in the IDE and also in the EXE with the same results.

 

[Imaginecorp]

Here is a shot in the dark; Is the database (dbc) that contains these 16 tables open?

 

[tacs]

Yes, there is a dbc and it is open. Not all of the tables are actually in the dbc some of them are free tables and cursors. Thanks anyway.

 

[Mike Lewis]

So, the bottom line is: You issue a SELECT command; the alias you are selecting is valid, and is open in the current data session; but the command doesn't actually change the work area. There's no error message.

To put it at its very simplest, you have:

SELECT SalesTable
? ALIAS()

and you see something other than SalesTable displayed on the screen.

If my interpretation is correct, I can't see any way that could happen.

Have I understood it correctly?

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[tacs]

That is totally correct, which is why I am so confused.

The only table showing as selected is the first table in the session. The select command, SELECT csrNew, results in no change to what I see as the selected table and if I try to index on a field that is not in the first table (the one it says I have selected), but which is in the csrNew which I have just selected I get an error because it cannot see the field. If I stop the program running and step through the debugger it works perfectly. If I use the command window and type SELECT csrNew, it selects it quite happily.

I have never seen anything like this, but I was hoping that someone else had, that I was having a mad momment.

It's nothing to do with the PC being used as I have also got a colleague to run it with the same result.

Thanks anyway Mike.

 

[Mike Lewis]

This is very rum. The only thing I can think of is that it has something to do with the grid having focus (as I mentioned in an earlier post). Perhaps you could try executing your code from the click or double-click of a different control, just to see if it makes a difference.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[Olaf Doschke]

I secon Mike, put that code in the click of a button for example, then the grid won't be able to reset the current workarea to it's recordsource.

Another reason I could think of is a timer, that selects a workarea, but I doubt that someone has done such a thing intentionally.

Bye, Olaf.

 

[Imaginecorp]

I must be missing something... What grid? the tables in the DE are not available to the form... Am I correct. In Debug everything works...
This is very strange unless there is a "clear all" after the first table is selected. But the Debug should not work if there is a Clear All.
Please Post back if you have solved this... Thanks

 

[Olaf Doschke]

Imaginecorp,

tacs wrote about a grid being on the form in question several times. And grids can reset the active workarea, when they get or have focus. It's a known problem when you do SELECT somealias and right after that REPORT FORM ... will have the grid recordsource alias as it's active alias. You solve that by either a DE of a report, which surely takes control over datasession, aliases etc. especially, if it's a private datasession. But you can also solve it by setting focus to some other control before REPORT FORM.

That's why I support Mike's ide to let tacs put the code in another control, perhaps a button's click event to see what happens then.

By the way, tacs: The form being modal or not just makes a difference in that a modal form will run until it closes, while a nonmodal form initialises and then returns control to the caller before it closes. In case of running a form from the command window it makes a difference that you can debug it while it runs, therefore a nonmodal form is the better choice normally, you should perhaps set that back. The main point or question is, if the form has a private datasession or not, that might make a difference of what you see in the data session window opposed to what ? ALIAS() prints to the screen. You may need to switch the session in the datasession window in upper middle combobox to see the session of the form, if the command window and debugger are in the general session rather than the form's session.

Bye, Olaf.

 

[Imaginecorp]

Ah; I see the reference to the grid now...

 

[tacs]

Thanks for your posts guys. I'm not on site now until Monday so I will try out the idea of moving the control to a button away from the grid when I get back.

I have taken a screen shot of the debugger which show it paused immediately after the SELECT command. You can see the data session window has the cursor open and not selected and finally the watch window shows the current ALIAS() as a different table. If I attach this as a JPEG will it show OK here? I can put it on a web site to get the URL.

This code does do a select and then run a report, but I also have seen this happen here where I select a table, but the program remains sitting on a temp cursor. After using the SELECT I tried to create an index which failed because the field I was indexing was not in the cursor. Also, I have checked the report and it does have the cursor I am trying to select this time in it's environment.

The problem seems to occur within the double click event of the form. The odd thing (even more odd) is that it does a replace into this cursor and if I pause it and check the contents or even stop it and check the contents of the cursor it seems to have replaced successfully. Truely strange.

 

[tacs]

Sorry, I just read that back and I should add this.

When it does the replace it doesn't use an alias. It does a SELECT then REPLACE fieldname with .......

I could deal with it if the debugger was simply out of step, it could be I suppose, but where I tried to index and here where I try to run a report it clearly IS on a different table.

Again, I won't be able to check until Monday, but could this have anything to do with buffering? I have seen and had various issues with that here.