Error "Alias table not found"

[keepfoxing]

hello everyone!
i am using a table in all my forms and my problem is when i'm loading a form, the error message: "Alias table not found".

for example: i have 3 forms (splash,login,main)

when i run the forms from splash -> login -> main then that is the time the error will popup
but if i run the forms individually, no errors at all.

in every form, i used this code to select a table:

select table

and this line also is where the error points.


any help would be appreciated..thanks in advance

 

[Tore Bleken]

Are you aware that Table is a reserved word? That may very well be why you have this problem.

 

[Scott24x7]

Keepfoxing,
If you are using the Data Environment function, check the form that it doesn't run on to see if your table is in the data environment. Or, somewhere in your code you should have something like:

IF NOT USED('MyTable')
SELECT 0
USE MyTable
ELSE
SELECT MyTable
ENDIF

I'm assuming your use of "TABLE" above is for demonstration, ast Tore points out TABLE can't be the name of a table...


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

The error is just telling the table isn't opened.

I'll take for granted the forms run when started single in the VFP IDE.
That's strange. Are all forms using the default datasession?

Did you really put the tables to be used by the forms in the ddataenvironment or do you open them manually (or in code) before starting the forms?

Bye, Olaf.

 

[Mike Lewis]

Is it possible that the Main form has a different data session from the other two? You can check that by looking at the forms' DataSession and DataSessionID properties.

The point is that, if you open a table in one data session, that does not cause it be open in other data sessions. You have to explicitly open it in every data session where you plan to use it. And if a table isn't open when you issue a SELECT command for it, then you will get the error that you are seeing.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Are you aware that Table is a reserved word? That may very well be why you have this problem.

I'm assuming your use of "TABLE" above is for demonstration, ast Tore points out TABLE can't be the name of a table...

Actually, you can have a table named Table, and doing so won't produce an error. To be exact, "table" is a keyword, but it is not a reserved word.

That said, I would agree that Table is not a sensible name for a table, and should definitely be avoided. I only mention this point so as not to distract attention from the real cause of the problem.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

In addition to all of the good information that others have supplied above....

when i'm loading a form, the error message: "Alias table not found".

What have you done yourself to identify the source of your problem?

Have you put either a SET STEP ON just above the problem line or put a Breakpoint (as long as the TRACE window is already open) on the line itself and then executed the code?

If so, you should be able to then use the

VFP top-level Menu - Window - Data Session​

to see what tables are in USE and which one, if any, show as highlighted (SELECTED).
That Data Session window will show the various Aliases of the in USE tables.

If you find that there is nothing in USE that has the Alias "Table" then - you found your problem.

Good Luck
JRB-Bldr

 

[Tore Bleken]

Mike,
you may be right that Table is a legal table name, but still it's dangerous to use since you must be extra careful. And Table is in deed in the "official list" of reserved words, have a look in Help. To show you why you should avoid reserved words, run this code and experiment with the values.

[pre]Create Cursor _screen (height i, width i, visible l)
Insert Into _screen (height, width, visible) Values (500,500,.t.)
Browse[/pre]

 

[Mike Lewis]

Tore,

Of course Table is dangerous to use as a table name. That's pretty well exactly what I said. But I repeat that that is not the cause of this particular error.

If you execute this code:

[tt]CREATE TABLE Table (f1 char(6))
SELECT Table[/tt]

it will indeed create and select a table named Table.

Of course it's a silly thing to do, but - as I also said - Keeepfoxing shouldn't allow this to distract his attention from the real cause of this particular problem (which we are now no further forward in solving).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

We appear to be hung up on using "table" as an alias.

The actual error message is "Alias <name> not found". If that is what the OP meant, then we've spent several posts arguing about several things and not come any closer to finding an answer.

Can we find out what the actual error message was?

 

[Tore Bleken]

Many people ask a question, but never give us any feedback later. If this problem isn't solved yet, I ask to see the actual code that fails, and the code that precedes it. Best of all would be to see code that we can run to reproduce the error.

 

[keepfoxing]

sorry for the late response, kind of busy..
i have already solved that problem but in connection to it,

im using one table in two forms, when i load the first form there is no error, but when i load the 2nd form, the grid displays nothing or blank when the 1st form was closed.

any solution to this..

 

[Mike Lewis]

i have already solved that problem

It would be really helpful if you could tell us what the solution was - partly for the benefit of anyone else with a similar problem, and partly as a courtesy to those who spent some effort in trying to help you.

Regarding your second problem, it sounds as if the two forms share the same data session (see above posts for more information about data sessions). When the first form closes, it automatically closes the table (because the first form's DataEnvironment's AutoCloseTables propert is .T.). Hence there is nothing to display in the grid.

Mike





__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

As I asked "Are all forms using the default datasession?" this was not hinting on using the same datasession as solution. It really just was a simple question to not write a bunch of things for this or the other case but only the half of it, that you'd need to know.

As you now do use default session, that solves the initial problem, but if your forms should run independent from each other and the closing of one shouldn't pull the rug from under other forms, then you better not use the default session for all forms.

Indeed the best practice is to have private datasessions for all forms and I proposed this in many occasions.

Both things have advantages and disadvantages, eg you need to put the table you want to share in every forms dataaenvironment and on top of that, if forms should be synced on the current record position, you have to let forms inform each other about their current position, as the table is in different workareas of different sessions and don't share a record pointer.

If forms share a datasession they can't close until your finished with the data overall, eg sub forms should close before main forms, which could be controlled by making subforms modal. So there are several ways of doing things, but each needs a set of rules you apply. When forms share a session you have a logical formset, though not working with a real formset. Another thing you can do about the dataenvironment is set it to not close tables. That happens anyway, if the last use of the datasession finishes. The one thing, that is worst with all forms sharing a general datasession is that it gets convoluted. What I recommend is sometimes sharing the session, if that is making things easier, but obviously you need support code keeping things in sync in both cases. There is no automatic intelligence preventing a table to close, if it's still bound to a control elsewhere.

Bye, Olaf.