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

 

[stanlyn]

>> The form failed to instantiate because an error happened when it tried. If an error happens instantiating any contained control, that error percolates out to the container (form) and prevents the whole shooting match from loading.

The form does load, however when stepping thru the code I observed the error that currently is not an error because at the time the form is loading and creating the object reference to thisform, it actually will not error until you use it as in goThisform.Caption = 'Something'. This is not occurring until it starts processing a job in which I use the goThisform to update a status window from an external program. It has always worked. I'll need to block out a couple hours to find it. I should not be having to deal with something so simple... Now the "run as a service" is a much bigger issue...



>> What does the OTHERWISE condition report in the error handler?

This is what is in the otherwise clause and it is not being shown... as I have On error set step on...

OTHERWISE
MESSAGEBOX('Error #: ' + TRANSFORM(nError) + CHR(13) + ;
'Message: ' + TRANSFORM(MESSAGE()) + CHR(13) + ;
'Program: ' + TRANSFORM(PROGRAM()) + CHR(13) + ;
'Line #: ' + TRANSFORM(LINENO()))

 

[stanlyn]

Concerning the network permissions, I changed it to use the administrator account and so far I haven't seen any differences. To be fair, I have not really tested it because of these new issues.

More later, once the other prob is solved...

 

[stanlyn]

>> Another question: Why did you just mention _vfp.activeform, or why did you expect it to hold a form reference,

Because in the form's init I set
goThisform = _vfp.activeform
to establish a global reference to that form so the external export.prg can write to a status box on the form.

This has worked for years flawlessly, and now when I step thru the form's init it is showing as a logical .F. instead of an object...

Even when I put "_vfp.activeform" into the debugger, it show "Expression could not be evaluated...

Currently, I'm using an ideal someone mentioned earlier as in
DO FORM 'Syncer' NAME goSyncerForm LINKED NOSHOW With Alltrim(Prompts)
goSyncerForm.Show()

This is what has worked flawlessly for years and is commented out now...
* Do Form 'Syncer' With Alltrim(Prompts)
* Possible values for Prompts are 'Auto' or 'Interactive'

 

[stanlyn]

Now, I placed

If Type('goSyncerForm') <> 'O'
Public goSyncerForm
Endif

goSyncerForm = _vfp.ActiveForm

at the bottom of the form's init event and the variable goThisform equals .F.


What happens when you try that, it should be set as an object to thisform that contains the init...

What is your result

 

[stanlyn]

OK, I've got that "goSyncerForm stuff" working by taking it completely out of the form's init and placed it in the command button that starts the job (which is where it should have been all along... Don't know why it decided to stop working after many years...

Now, I'll get back on topic...

 

[Olaf Doschke]

You had that in init? I'd assume _vfp.activeform never worked, as the form only get's active after init, no matter how you start it. Activate Event comes after Init.

I'm puzzled, too, how it could have worked for many years. Something had to be different...

Bye, Olaf.

 

[Dan Freeman]

You're careening all over the place and it's all because of fundamental misunderstandings of how variables are scoped and the model VFP follows. You're flailing.

If you need to store an object reference to a form during the form's Init method, use THIS. i.e. goForm = This

As Olaf says, Activeform has not been populated yet during INIT because if INIT fails there cannot be an Activeform.

>> What does the OTHERWISE condition report in the error handler?

This is what is in the otherwise clause and it is not being shown... as I have On error set step on...

OTHERWISE
MESSAGEBOX('Error #: ' + TRANSFORM(nError) + CHR(13) + ;
'Message: ' + TRANSFORM(MESSAGE()) + CHR(13) + ;
'Program: ' + TRANSFORM(PROGRAM()) + CHR(13) + ;
'Line #: ' + TRANSFORM(LINENO()))

You did not answer the question I asked, but you've since changed 40 other things so all bets are off. When did you add this? What did it report? The last time you said anything about it you'd deleted the OTHERWISE entirely and didn't have an error handler.

That's a LOT of changes without bothering to tell the people trying to answer your questions based on information you previously provided.

Reading recent posts, I'm no longer sure I know what your question is. It seems to have changed, but I'm not sure.

 

[Olaf Doschke]

In regard to ON ERROR SET STEP ON, this is only working in the IDE, set step on is ignored in EXE startmode, both as EXE and as service, doesn't matter, it's always _vfp.startmode 0.

Have a real error handler there, vfp gives a good start in the help on ON ERROR.

I already said early on: You can't debug at runtime, you only can debug inside the IDE. ("the debugger always runs in IDE mode only." from 14 Sept 11 5:36)

Bye, Olaf.

 

[Dan Freeman]

Outside the IDE, ON ERROR SET STEP ON is exactly the same as ON ERROR *

Either one completely ignores all errors.

I'm getting the impression that somebody REALLY DOESN'T WANT TO KNOW what error is happening. ;-)

 

[Olaf Doschke]

Many things point toward a totally different issue than just solving your mystery here. Eg if you do backups the reproduction of the coverage log would simply be possible with a restore of the backup of the project as it was initially.

I'll make a summary of recommendations you got and didn't yet give feedback on:

1. reinstalling phd, to the get original phd.prg/fxp
2. setting build options to NOT recompile all files, especially after having reinstalled the original phd.
3. granting access rights to your database to the system windows account LOCAL SERVICE or NT AUTHORITY\NetworkService
4. introduce error handling before the form runs.

In regard to (3) you could also use the service properties dialog to change the setting of the windows account running the service to a normal domain user, eg to yourself, this would be the major difference between running in IDE or as EXE in contrast to running as a service, but you didn't even react to that recommendation yet.

It seems you don't attentively follow this thread.

Bye, Olaf.

 

[stanlyn]

Hi,

Well it looks like a lot was said after I had to move onto other pressing issues. I can't afford the luxury of spending days and days on implementing wish list items. If they happen fast, then great, its just that I don't have an infinite amount of time. I had given 8 days to this one problem along with others when I was forced to move on. I thought everybody had jumped ship after noting that I had made 5 entries without any replies. And when Olaf stated that he was puzzled, I realized that I had to move on and check back later...

Anyway, I'll retry this by applying the given recommendations, and sorry for what appeared to be abandonment on my behalf. I didn't, as I'm posting this now...

Thanks for the posts and recommendations,
Stanley