Error instantiating table

[audiopro]

I have an POS app which hsa been in use for years and I am making some changes to it.

Testing on my network shows no errors.

Running it on the client's live network throws and 'Instantiating Table' error when I run a particular admin form. The form has a number of tables set in the environment and throws the error when the the form is initially run.

How do I find out which table is causing the error?

This app has been working with no problems for years and I have not made any changes to the tables, ie. make read only etc.

Keith

http://www.studiosoft.co.uk

 

[Mike Lewis]

Hi Keith,

How do I find out which table is causing the error?

Have you tried removing one table at a time until the error goes away?

Obviously, you won't be able to run the form properly, but you should eventually get past the error.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

This is not even a native foxpro error message, what is the message 1:1? If it really contains the words "Instantiating Table", look out for your code where you output this.

Besides, if the error is not finding a dbf, look out what you do. In a DE paths to the table are show relative in the IDE, but are stored absolute, you need SET PATH settings inclucding the real location of the DBFs and perhaps DBC to make a DE work in the production environment, too.

Bye, Olaf.

 

[audiopro]

Hi Mike
I thought of that but the client is many miles away and I send updates to him via a server.

I thought there would be a way of telling which table caused the error. I am in the process of re-writing some of the admin form. It is quite a simple form, with about a dozen function buttons.
If one at a time is the only way then that is what must be done.



Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Well, of course you'd get the table name that can't be opened by an error handler.

If it's file not found you get the file name of the not found dbf. Eg simply try USE sdfhsdhfksjf in the command window. Be warned tough, that if foxpro doesn't find a file it may report a path it last searched, not the initial path being searched, but the last. You can rely on the filename, though, it's the filename it looks for.

But again instaciting table is even the wrong term, an object is an instance, a table has no instance, it is opened. And there is no such error message in the native list of error messages of foxpro.

Bye, Olaf.

 

[audiopro]

I can't remember the exact wording of the error message but it goes along the lines of

'Error instantiating table or one of it's members'
It is not something I have added to my error handler.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

or one of it's members" is part of error 1881:

Error loading file - record number n. "object" <or one of its members>. "Issue": "error".

This would mean your form has a problem in some record, a form actually is stored in a table eg USE yourform.scx and you'll see that.

To see what's wrong you need the exact message, add saving the exact message in a text or dbf file to your error handler. If it's not reproducable, good luck you'll see it soon again.

Bye, Olaf.

 

[audiopro]

I have rolled this form back to the bare bones and I have 3 tables in the Data Environment. The app ran on both network machines without error. A couple of hours later, the office computer could not access the admin screen and threw an error.

This is the Error message - very anonymous and darned annoying.

Error loading file - line number 6. Form 1 (or one of its members). 
Loading form or the data environment: File access is denied.

All tables have Exclusive set to false.

I have the same app set up on my office network and that functions without any errors at all. The only difference is, on my network, I do not use a receipt printer.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

This file access error does happen loading the FORM, not the tables. Datqaenvironment also is part of the FORM. It contains what table to open, but if the error was about the table access being denied it would be another error.

File Access is denied towards the SCX,VCX or the EXE file containing the SCX or VCX, perhaps because of concurrent usage.

Don't share the EXE or other code files among users, let everyone have their own local installation.

Bye, Olaf.

 

[Olaf Doschke]

additional:

let your forms run with more specific names than "form1" and you get more specific error messages. As you already seem to know it's the admin form you may inspect record number 6 from it. USE adminform.scx, GOTO 6, Browse.

If it's new to you that scxes actually also are just tables you will likely not be able to see anything wrong about that record. From the outset it also seems not to be an error with the scx or exe in general, just a concurrent access problem. Even if progrram for shared data access, you don't have influence of how the EXE is loaded, so as initially recommended: Let everyone have their own copy of the EXE. Let them start a batchfile copying from a central repository you can update anytime, and let that batchfile make an xcopy or robocopy of the exe and runtime dlls to a local drive and start from there and then there is no concurrent usage of the exe anymore.

Bye, Olaf.

 

[audiopro]

I am not sure I understand some of that Olaf but thanks anyway.
I am a bit confused as to what the under lying cause could be as this app has been running faultlessly for a number of years.

The error only occurs when the admin form is run from the office machine, all other forms work on both machines without any troubles at all.



Keith

http://www.studiosoft.co.uk

 

[audiopro]

I didn't know that forms were tables so thanks for the info.
I have been delving a little further and it appears that the problem lies with a cursor.
The records properties show:-

Left = 430
Top = 20
Width = 91
Height = 90
Alias = "daysales"
Order = "date"
CursorSource = daysales.dbf
Name = "Cursor3"


Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Then the logical thing to try is taking that out of the DE and then readding it again. Maybe the path changed, maybe there is no index tag "date" anymore, so the order of the table fails.

Bye, Olaf.

 

[SnyAc]

file access denied sounds like a privledges problem... could be on a temporary file path...

Andy Snyder
SnyAc Software Services

http://www.snysoft.com

Hyperware Inc. a division of AmTech Software

http://www.hyperwareinc.com