Intermittant error: "Alias not found" in VFP from ASP calls

[dbMark]

Ok, I get my data all the time from FoxPro tables. I access them from ASP pages with VBScript calls via "COM server" .EXEs to VFP projects (version 6 sp5) with the code to fetch the required data. This is the same ASP version we've been using for the past 3-4 years.

I've had to change the following code to avoid the use of using the table's ALIAS name when selecting a work area. Sometimes I get Error 13 Alias "MYALIAS" is not found.

Upon reviewing our logs, I sometimes saw this error following Error 24 Alias name is already in use. I think we tracked most of those issues down to the fact that when we exited the routine and returned to ASP, and then made another call from ASP we expected to be in the default workarea 1 but it remembered another workarea from the prior call. I think and hope, though, that we eliminated any such ambiguous code and if our code selects any work area other than 1, then we explicitly SELECT 1 before terminating and returning to ASP.

Is this a known web issue? Are quotes discouraged, optional or encouraged? Any suggestions would be helpful.

USE X:\mydata\mytable ORDER myorder ALIAS myAlias IN 2
SELECT myAlias  && <-- I get occasional errors here
* code *
USE IN myAlias

&& changed to:

USE X:\mydata\mytable ORDER myorder ALIAS myAlias IN 2
SELECT 2  && <-- No more errors?
* code *
USE IN 2

dbMark

 

[BPeisch]

First, I would suggest opening your table this way:

SELECT 0
USE X:\mydata\mytable ORDER myorder ALIAS myAlias

It's too easy to lose track of what's open in which work area by number, and it hasn't been necessary since the FoxBASE days. Doing a SELECT 0 says, "Select an unused work area". You can also add an IN 0 to the end of your SELECT command, but since you're selecting that alias right after, you might as well use code that makes it the current work area right up front.

Now, as far as your problem goes, I suspect that 1. You've turned off error trapping somewhere in your code with ON ERROR *, and 2. When you run the first set of code, the table is already open in another work area, but you're not getting an error because you've turned off error trapping.


-BP (Barbara Peisch)

http://www.peisch.com

 

[dbMark]

We've been programming to always close every table and return to work area 1 before exiting. Since we expect all tables to be closed when we enter, we don't USE mytable AGAIN which would allow one table to be open in another work area.

Many of our routines start with this code but possibly some routines don't use it to abort the routine:

this.resetError()  && routine use this call to reset error variables
*
protected procedure resetError
	this.errNum = 0
	this.errLine = 0
	this.errProg = ""
	this.errMsg = ""
	this.retMsg = ""
	return
endproc

I guess I just needed to know whether there was some weird fluke where ASP->VFP->SELECT <alias> might fail. In that case we'll have to examine every routine to verify which may not behave as expected.

Could this be the scenario? A routine fails and leaves a table open. Control returns to the ASP page where the next call to VFP finds that table open in another work area. We've already learned the hard way that if you leave VFP in a work area and reenter VFP you're still wherever you were last. Maybe the tables are still open, too?

Although some of our older ASP code placed VFP objects into session variables that can span several ASP pages during a session, we're trying to move away from that by placing objects into local ASP variables and setting them to nothing (closing them) at the end of the page. Would that new logic still allow the "memory" of prior work areas and tables in use to propagate to the following ASP pages?

dbMark

 

[dbMark]

Oh, you asked about ON ERROR. Yes, we use the VFP routine named error() to trap errors that takes precedence before ON ERROR, but mainly to record them. Oh, and it only records the first error until the next reset point, probably so we don't abort too quick on a minor error nor get a huge list of errors in the log. Hmmm...

procedure init
	sys(2335,0)  && make any display a trappable error
	set talk off
	set status off
	set cpdialog off
	set resource off
endproc

procedure error  && this error procedure takes precedence over 'on error' command
lparameters nError, cMethod, nLine, cMsg
   local tempSel
   tempSel = select(0)  && returns current work area
   if this.errNum = 0   && only the first error is recorded
      this.errNum = nError
      this.errProg = cMethod
      this.errLine = nLine
      if type("cMsg")="C"
         this.errMsg = cMsg
      else
         this.errMsg = message()
      endif
      use \\myServer\myLogs\weberror in 0 alias ErrTable shared
      select "ErrTable"
      append blank
      replace err_date with date(), ;
              err_time with time(), ;
              err_numb with nError, ;
              err_line with nLine, ;
              err_prog with cMethod, ;
              err_msg  with this.errMsg
      use
      select (tempSel)  && back to original work area
   endif
   close databases
   * (old) comreturnerror("Web Server Processing Error","Error "+ltrim(str(nError))+"  Line "+ltrim(str(nLine)) + "Method "+alltrim(cMethod))
endproc

 

[BPeisch]

I guess I just needed to know whether there was some weird fluke where ASP->VFP->SELECT <alias> might fail. In that case we'll have to examine every routine to verify which may not behave as expected.

No, I haven't heard of any such fluke. I don't think that's the problem.

Since we expect all tables to be closed when we enter, we don't USE mytable AGAIN which would allow one table to be open in another work area.

In my web apps that rely on everything being closed on each hit, I close everything on the way out, but also call my close routine at the start of each hit, just to make sure.

Is it possible that you're getting an error in your error procedure? That would leave tables open. Also, are you using both DBC tables and free tables? If so, a single CLOSE DATABASES will only close DBCs and any tables contained in them, but won't close free tables.


-BP (Barbara Peisch)

http://www.peisch.com

 

[dbMark]

Barbara, I can see you have earned your VFP MVP status. You have made some very good observations. Thank you so much.

This is what Microsoft says about the CLOSE DATABASES and CLOSE ALL commands:

CLOSE DATABASES [ALL]

Closes the current database in the current data session and its tables. If there is no current database, all open free tables, indexes, and format files in all work areas in the current data session are closed, and work area 1 is selected.

(Optional ALL keyword includes all open databases and their tables, except for currently selected databases in other data sessions or databases and their tables that are open in other data sessions.)

CLOSE ALL

Closes all open databases, tables, and indexes in the current and any inactive data sessions and selects work area 1. CLOSE ALL also closes any files opened with the FCREATE( ) and FOPEN( ) low-level file functions. CLOSE ALL does not close a file opened with SET PRINT.
CLOSE ALL also closes the following:
Form Designer
Project Manager
Label Designer
Report Designer
Query Designer

Since we use just one default data session and do not use either DBCs or transactions, the CLOSE DATABASES command should be doing what we expect, closing our free tables and selecting work area 1. Another option would be to use CLOSE ALL when we exit back to the ASP page. You have a good idea there to run the close routine upon entry to be absolutely sure the environment is as expected. Routines called internally will have to be careful, though, not to close when they're not supposed to...

I think I'll experiment a bit and post the results. In addition, a close review and synchronization of each routine is warranted here, just to be sure we are consistent. There's likely a routine or two that isn't updated to the current design specs.

Lastly, thanks for reassuring me there isn't some known issue here with ASP and VFP. (In a post a few months back I described an old VFP project executable where someone else had coded it with over 40 parameters coming in from ASP via COM. And it worked! We hit the limit somewhere around 54 parameters (my hazy recollection) and I redesigned it to use object properties/variables. Anyway, VFP is supposed to pass only 27 parameters, but I guess that's just within VFP, and from outside the limit might be stretched a bit.

dbMark

 

[flintstone42]

Also, I always if the
if not(used("myalias"))
use tablname alias myalias in 0
endif

Alias, I have found that VFP com object called from
asp pages usally do not have access to the driver names
So, I use the "shared" name instead
instead of
use x:\data\tablename
try
use \\computername\data\tablename

 

[dbMark]

flintstone42, I'm checking the concepts in your post.

While we already were using the network share names for access to tables on a remote server rather than using mapped drives, the problem arises with tables that are on the NT server itself. We open tables, often with indexes. No errors occur at that time. Then when we SEEK or get a field value we get an error that the table is not open or the index or variable doesn't exist.

Drive C: has the NT system and X: has most of the tables we use. Surely you're not saying that I shouldn't use x:\data\tablename when referring to the second partition of the local logical drives (actually part of a RAID of 3 physical hard drives)?

 

[dbMark]

I found this Alias Not Found bug description on Microsoft's support site. This may not be my exact problem since its example seems to deal with a table whose index tag includes the alias in the key expression, then the table is opened using a different alias. In my case I open a table (no error reported) then later, sometimes in the midst of a loop through several fields named fld1, fld2, fld3, etc. up to 40 or 80 such fields, and it gives me, intermittantly, "Alias 'aliasname' is not found" errors partway through the simple loop of these fields. In any case this bug acknowledgement is interesting.

http://support.microsoft.com/default.aspx?scid=kb;en-us;191315

Microsoft Knowledge Base Article - 191315
BUG: ON ERROR Does Not Trap "Alias Not Found" Error

SYMPTOMS: Visual FoxPro's ON ERROR command does not trap the following error:
Alias not found error (error 13).

STATUS: Microsoft has confirmed this to be a bug in 3.0b, 5.0, 5.0a, 6.0.

A sample program is provided on that web page to demonstrate how it can occur.