Why is a dummy table automatically created when ran as service 1

[stanlyn]

Hi, I'm adding "run as a service" support to my app. The app runs fine in development and as an .exe. However when ran as a service using a system account that interacts with the desktop it prompts for a table name. It doesn't matter what table I choose, it fails and automatically creates a dummy table and places it in the dbc.

Anyone know how I should troubleshoot and/or whay I should be looking for?

VFP9sp2 on XPproSp3

Thanks, Stanley

 

[Dan Freeman]

Is the "dummy" table named foxuser.dbf?

 

[Olaf Doschke]

If it's not the foxuser.dbf, it's what your code must do, because besides foxuser.dbf there is no other automatism creating tables.

What speaks agains foxuser is, that vfp won't prompt for a missing one, it would just create one and may error "... is not a valid resource file", if it finds one being corrupted.

One very simlpe way to see if the unwanted prompt for a table is done by the startup of vfp or your code is to put a messagebox() as your first command in your main.prg, if the prompt for the table comes afterward, look into your code or third party components you're using.

Bye, Olaf.

 

[Dan Freeman]

Yup, the question is vague enough I wasn't sure but it has all the earmarks (a service) of an app that gives different behavior out of the blue when it's finally packaged for deployment instead of running from the IDE.

The other possibility, and you've described it, is that when the app is run as a service the default directory is different so it can't find the data that it could find in the IDE.

Judicious use of a config.fpw can solve either problem, but MIGHT not be the best solution depending on the actual problem. As you know, setting DEFAULT=<path> in config.fpw will solve the problem of not finding data but adds new problems down the line when the app moves.

A quicker way to find the problem of what's asking the question is SET TABLEPROMPT OFF, which will give an error message instead of prompting for a table when a USE command fails. Errors are always easier to find.

 

[stanlyn]

> Is the "dummy" table named foxuser.dbf?

The actual name of the table is dummy.dbf and can be viewed by opening up the dbc.

I did not pay attention to the field names, of which I will do.

Shouldn't the foxuser.dbf always contain the same field list as any other foxuser.dbf? I know the data would be different between apps, but I should be able to tell by the field list if was actually the foxuser.dbf that was being created as dummy.dbf.

Stanley

 

[stanlyn]

> What speaks agains foxuser is, that vfp won't prompt for a missing one, it would just create one and may error "... is not a valid resource file", if it finds one being corrupted.

I have "set resource off" early in the startup prg, so why would a foxuser.dbf actually be used/created?

Stanley

 

[stanlyn]

Is it good practice to always use "SET TABLEPROMPT OFF" in an app? I've never used it, but I can see how "use" errors could be found easier...

Stanley

 

[stanlyn]

OK, after some changes, the top of my main.prg looks like this

Parameters Prompts
* Possible values for Prompts are 'AUTO' or 'Interactive'
* Main.prg for all Versions

MESSAGEBOX("Hello from Syncer...")
SET TABLEPROMPT OFF

Hide Window Screen
Set Resource Off
...............

When run by the service, it shows the messagebox and after oking the messagebox, it presents the select a table dialog, even though I have "set tableprompt off"

I then cancel and open the dbc and sure enough, there is a new table there named "dummy.dbf" with one field named dummy which is empty. I right click the table and delete it from the dbc...

The app and pathing info in the registry look like this

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DriSyncSrv\Parameters]
"AppDirectory"="c:\\Stan-Lyn\\SyncDRI"
"Application"="c:\\Stan-Lyn\\syncDRI\\syncdri.exe"
"AppParameters"="AUTO"

What next?
Stanley

 

[Koen Piller]

Hi,

If you have a table dummy.dbf in your application I suspect you also have a code creating such a table since this is not default vfp behavior. If it is not your code please check your application for 'dummy' with either Code References or GoFish.

Regards,

Jockey(2)

 

[Olaf Doschke]

Ok, you found out the creation of the table is not done by foxpro itself in the start process. Also setting Tableprompt off does not hinder VFP to let you choose some file via GetFile() dialog or another self defined dialog.

As it's happening early on, you can SET COVERAGE TO cover.log and then kill the exe via taskmanager, when prompted for a table. The line causing the prompt would then be recorded in the log file, already.

In regard to your question about SET RESOURE OFF: Even if done as the first line of your main.prg, it's too late already. The only chance to make a VFP exe not use or try to create a foxuser.dbf is to start it via a config.fpw with RESOURCE=OFF or even include that config.fpw in the project, so it's included in the build and part of the EXE.

But that just as a side note, as VFP does not create a foxuser.dbf with another name.

Other automatic code could be executed via DBC Events, eg when opening the DBC, if you have a DBC. And of course DEFAULT values can trigger code, even code creating a table.

It must be part of your code, something you may have forgotton you've done or something part of third party components you use, which could also be the code you use to make the VFP exe run as a service.

Bye, Olaf.

 

[stanlyn]

OK, I found it... It is phd.prg which is part of phdbase the full text indexer. At the top of the file it mentions the code does not get run but needs to be compiled into the prg to avoid some errors.

I added a messagebox inside it at the top to see if it was being executed. The messagebox only appears if started as a service, and NOT in dev mode or as an .exe in the ide.

Here is the last few lines from the coverage log
0.000007,,frmsyncer.error,33,c:\stan-lyn\syncdri\forms\syncer.sct,6
,,syncexport,125,syncexport.fxp,5
,,frmsyncer.error,3,c:\stan-lyn\syncdri\forms\syncer.sct,7
,,frmsyncer.error,4,c:\stan-lyn\syncdri\forms\syncer.sct,7
,,frmsyncer.error,18,c:\stan-lyn\syncdri\forms\syncer.sct,7
0.000009,,frmsyncer.error,32,c:\stan-lyn\syncdri\forms\syncer.sct,7
0.000007,,frmsyncer.error,33,c:\stan-lyn\syncdri\forms\syncer.sct,7
,,phd,9,phd.fxp,6

and here is the top of the phd.prg
*
* Include this code in your project to avoid the "feature not available"
* error message when a PhDbase III command is issued.
*
* Note that the code need not be executed -- just compile it in with the app.
*

if .F.
MESSAGEBOX('Inside phd')
erase dummy
delete tag dummy of dummy
wait window nowait "dummy"
wait clear
index on .T. tag dummy unique
use dummy in 1 alias dummy again exclusive noupdate
use ? <--------- This was generating the select table dialog...
set index to dummy order dummy

So, what would "run as a service" be doing different from any other run type?

Stanley

 

[Dan Freeman]

Did you truncate phd.prg?

It should at the very least have an ENDIF in there.

The comments explain exactly what that code is for, but it was very much included for FPW (the predecessor to VFP) and its usefulness today is questionable.

I'm actually a little surprised to see phdBase even mentioned. I thought it died a decade ago.

 

[Dan Freeman]

Make that two decades. Time flies.

 

[Olaf Doschke]

If it's really inside an IF .F. this code never runs, can never run, no matter in what mode the runtime is, IF .F. means never. Or did you put that in yourself now?

Bye, Olaf.

 

[stanlyn]

>> its usefulness today is questionable
I haven't found a better replacement... Its super fast on small and large tables alike.
In this Syncer app that I'm adding the "run as a service" functionality, I have to use it as its running against a structure that uses it...

>> Did you truncate phd.prg?
Yes, here is the entire prg...

*
* Include this code in your project to avoid the "feature not available"
* error message when a PhDbase III command is issued.
*
* Note that the code need not be executed -- just compile it in with the app.
*

if .F.

MESSAGEBOX('Inside phd')

set talk on
set talk off
set safety on
set safety off
set delete on
set delete off
set escape on
set escape off
erase dummy
delete tag dummy of dummy
wait window nowait "dummy"
wait clear
index on .T. tag dummy unique
use dummy in 1 alias dummy again exclusive noupdate
*use ?
set index to dummy order dummy
set order to dummy
set odometer to 100
set message to "dummy"
on error ?
define window dummy at 1,1 size 1,1 font dummy
activate window dummy
move window dummy center
release window dummy
release dummy
push key clear
pop key
keyboard "x"
locate for .T.
continue
count for .T. to dummy
on key label F1 ? dummy
flush
replace dummy with 0 for .T.
create cursor dummy (dummy n(4,0))
create table dummy (dummy n(4,0))
insert into dummy values (0)
dimension dummy(1,1)
set relation to dummy into dummy
go top
browse normal nowait
@0,0 say 'dummy'
* @0,0 say 'dummy' bitmap center
@0,0 get dummy default 'x'
read
read cycle
modify memo dummy noedit window dummy
delete
quit
select dummy
? dummy
copy to dummy fields dummy
* copy to dummy foxplus
* copy to dummy dif
* copy to dummy mod
* copy to dummy sdf
* copy to dummy sylk
* copy to dummy wk1
* copy to dummy wks
* copy to dummy wr1
* copy to dummy wrk
* copy to dummy xls
* copy to dummy delimited with "x"
* copy to dummy with blank
* copy to dummy with tab
endif

 

[stanlyn]

>> If it's really inside an IF .F. this code never runs, can never run, no matter in what mode the runtime is, IF .F. means never.

Not true... The only thing I added was the messagebox. The messagebox does NOT show when running thru the exe ide or the dev env. The messagebox DOES show when running as a service, and also prompts for a table name which is shown after the messagebox as "use ?" of which I have commented out. It was that line that started this whole thread...

Any ideas?

 

[Dan Freeman]

What Olaf says is .t.

I certainly haven't encountered any place where VFP ignores such a basic programming statement, and there are other commands in that block that should be causing errors too.

But, hey, never say never.

Comment out the whole block and move on. Nothing there serves any purpose since FPW.

 

[Olaf Doschke]

Yes, I'd suggest the same, comment that whole block. It doesn't define anything vfp9 wouldn't know already anyway.

Nevertheless I'm very sure it's never run, because of IF .F.

You'd need to #Define .F. .T. to make that work or have some code copy the code after if .F. to a new file and execute that. Both very unlikely.

"Never say never". I'm tempted to say so, even though you report the messagebox runs. Are you sure it runs from that prg? Did you really recompile? IF .F. for sure makes no choice for VFP, unless you use a font displaying an F instead of a T.

Bye, Olaf.

 

[stanlyn]

i added the messagebox in an effort to see if the commented out "use ?" statement was running. This of-course was after the program was putting up the table selection dialog in "run as a service" mode. It works as expected when run in bothe the dev and .exe envs... I reported all this early in this thread when I was looking for what was causing the table selection dialog. I found it and it was the "use ?" statement in the phd.prg....

I will comment it all out and test, and I do expect it to work, hopefully.

If anyone would like to see a screencast of if .f. passing as true, just let me know...

Thanks, Stanley

 

[Olaf Doschke]

Hi Stanlyn,

Yes, I understand, and yes, I'd like to see a screencast of VFP stepping into IF .F.

But how would you create a screencast single stepping through code, when the code runs in the EXE in service mode? You can't, the debugger always runs in IDE mode only.

I repeat what I suggested earlier: SET COVERAGE TO cover.log to see what really is running. At the point of the table prompt dialog or the messagebox you can terminate the process and then see from the raw log file, if the message really comes from there and what lines where executed beforehand.

Come back with the end of the cover.log and then we'll see.

Bye, Olaf.