Re: Logging

Ha! Well now I need to make time to show that video. Civil War Reenactment log made me LOL. E On Wed, Aug 2, 2023 at 1:11 PM Ed Leafe wrote: > On Aug 1, 2023, at 15:15, Bill Anderson wrote: > > > > Well, the effects of deforestation and biodiversity come to mind... > > > > Did you have

Re: Logging

On Aug 1, 2023, at 15:15, Bill Anderson wrote: > > Well, the effects of deforestation and biodiversity come to mind... > > Did you have something else in mind? ;) This came to my mind: https://www.youtube.com/watch?v=FR-REDevAzk -- Ed Leafe

Re: Logging

something else in mind? ;) > > Bill > > On Tue, Aug 1, 2023 at 6:13 AM Eric Selje wrote: > > > I'm doing a session on logging at SW Fox. > > > > Just based on that information, what would you hope to see the session > > cover? > > > > Thanks, >

Re: Logging

Well I was as a forestry scientist tempted to respond similarly  On 2023/08/01 23:00, Paul H. Tarver wrote: I have written two products in VFP for the Timber Industry to help with them with logging. https://cruisecalc.com/ https://loadcalcpro.com/ Does that count? :) PS: Yes, I'm sorry

RE: Logging

I have written two products in VFP for the Timber Industry to help with them with logging. https://cruisecalc.com/ https://loadcalcpro.com/ Does that count? :) PS: Yes, I'm sorry that was terrible but Bill started it! :) Paul H. Tarver Tarver Program Consultants, Inc. -Original Message

Re: Logging

Well, the effects of deforestation and biodiversity come to mind... Did you have something else in mind? ;) Bill On Tue, Aug 1, 2023 at 6:13 AM Eric Selje wrote: > I'm doing a session on logging at SW Fox. > > Just based on that information, what would you hope to see the sessio

AW: Logging

... logging to Windows Eventlog. As well as reading that from VFP -Ursprüngliche Nachricht- Von: ProFox Im Auftrag von Eric Selje Gesendet: Dienstag, 1. August 2023 15:13 An: ProFox Email List Betreff: Logging I'm doing a session on logging at SW Fox. Just based on that information

Re: Logging

I'd be curious to see how to centralize the logging code and trigger it, what kind of system information is available to log alongside my own information, and maybe how to log to different backends such as dbfs, SQL backends, or an HTTP api. On Tue, Aug 1, 2023 at 8:13 AM Eric Selje wrote

Logging

I'm doing a session on logging at SW Fox. Just based on that information, what would you hope to see the session cover? Thanks, Eric --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html

RE: Event logging

:51 AM To: profoxt...@leafe.com Subject: RE: Event logging As Matt mentioned, GF5 has been out for a while and it is quite stable. If you decide to revisit the coverage profiler, this add-on for analyzing coverage logs can be quite helpful. It's a little rough around the edges but it does help

RE: Event logging

bit of code built into the load event of my baseform class that lets me turn on coverage logging as needed. <http://gorila.netlab.cz/cvp.html> -- rk -Original Message- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Ted Roche Sent: Wednesday, September 06, 2017

Re: Event logging (GoFish)

The latest version of GoFish is GoFish 5.0.163 released 2017-02-12 You can get it through Thor, or from this download link: https://github.com/mattslay/GoFish/archive/master.zip The project has moved from VFPx/Codeplex to GitHub. Here's the link to the new repo on GitHub:

RE: Event logging

ore than enough information >to get going on tracking down the poor performance. > >Dave > >-Original Message- >From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Frank >Cazabon >Sent: 06 September 2017 16:30 >To: profox@leafe.com >Subject: Re: Event logging >

RE: Event logging

Sent: 06 September 2017 16:57 To: profox@leafe.com Subject: Re: Event logging On Wed, Sep 6, 2017 at 11:30 AM, Frank Cazabon <frank.caza...@gmail.com> wrote: > You could use the coverage profiler. > > Frank. > Some pointers: http://spacefold.com/lisa/oldsite/LSN_CoverageExten

RE: Event logging

September 2017 16:30 To: profox@leafe.com Subject: Re: Event logging You could use the coverage profiler. Frank. Frank Cazabon On 06/09/2017 11:16 AM, Dave Crozier wrote: > Fellow Foxers, > Just a little aside to late Wednesday afternoon: > > I have a heavyweight data entry pr

Re: Event logging

On Wed, Sep 6, 2017 at 11:30 AM, Frank Cazabon wrote: > You could use the coverage profiler. > > Frank. > Some pointers: http://spacefold.com/lisa/oldsite/LSN_CoverageExtend.aspx ___ Post Messages to: ProFox@leafe.com

RE: Event logging

. Dave -Original Message- From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Koen Piller Sent: 06 September 2017 16:33 To: ProFox Email List <profox@leafe.com> Subject: Re: Event logging Dave, 1) I would install GoFish4 this application can list you all the calls to Refresh(

Re: Event logging

statistics to have a look at where all the processing effort is going? All I can think of is to programmatically bind a "logging procedure" event to each control's refresh event and then log the results into something like a csv table for further analysis or at worst, log events by collect

Re: Event logging

ics to have a > look at where all the processing effort is going? > > All I can think of is to programmatically bind a "logging procedure" event > to each control's refresh event and then log the results into something > like a csv table for further analysis or at worst, log ev

Event logging

cally bind a "logging procedure" event to each control's refresh event and then log the results into something like a csv table for further analysis or at worst, log events by collecting information from the refresh events in the base classes for each control but that would be very lon

Multiple instances of app running (was Re: How do I keep an operator from logging in twice from the same computer)

On 2015-12-10 10:11, Mike Copeland wrote: I KNEW I was missing some detail...crashless apps! Perfect! I'm gonna put that in all my apps, right now! Thanks! :) Mike Copeland Been pondering this with respect to my apps. I wouldn't want to limit the user like this. I don't see the

Re: Multiple instances of app running (was Re: How do I keep an operator from logging in twice from the same computer)

Well Mike I never used to do this until I got fed up with users complaining about how slow their pc was. On checking it I found multiple instances of my app running because the user had minimised it and forgot so opened it again,minimised that one, forgot , opened it again etc etc. If you want to

Re: Multiple instances of app running (was Re: How do I keep an operator from logging in twice from the same computer)

Wait...this isn't a VFP function Dang... if crashless('appnamehere') nocrash=.t. endif Mike Stephen Weeks wrote: Well Mike I never used to do this until I got fed up with users complaining about how slow their pc was. On checking it I found multiple instances of my app running because

Re: Multiple instances of app running (was Re: How do I keep an operator from logging in twice from the same computer)

On 2015-12-10 15:32, Stephen Weeks wrote: Well Mike I never used to do this until I got fed up with users complaining about how slow their pc was. On checking it I found multiple instances of my app running because the user had minimised it and forgot so opened it again,minimised that one,

Re: Multiple instances of app running (was Re: How do I keep an operator from logging in twice from the same computer)

No crashes: ON ERROR * ;) Fred On Thu, Dec 10, 2015 at 1:32 PM, Stephen Weeks wrote: > Well Mike I never used to do this until I got fed up with users > complaining about how slow their pc was. > On checking it I found multiple instances of my app running because

Re: Multiple instances of app running (was Re: How do I keep an operator from logging in twice from the same computer)

On 2015-12-10 16:16, Fred Taylor wrote: No crashes: ON ERROR * ;) True story, Fred: I was contacted to take a look at this water/sewer billing software written in Foxpro that would often hang/freeze but they didn't know why. I open it up and there it is: ON ERROR * I kid you not.

Re: Multiple instances of app running (was Re: How do I keep an operator from logging in twice from the same computer)

At 12:32 2015-12-10, Stephen Weeks wrote: Well Mike I never used to do this until I got fed up with users complaining about how slow their pc was. On checking it I found multiple instances of my app running because the user had minimised it and forgot so opened it

Re: Multiple instances of app running (was Re: How do I keep an operator from logging in twice from the same computer)

On 2015-12-10 19:55, Gene Wirchenko wrote: At 12:32 2015-12-10, Stephen Weeks wrote: Well Mike I never used to do this until I got fed up with users complaining about how slow their pc was. On checking it I found multiple instances of my app running because the user

Re: How do I keep an operator from logging in twice from the same computer

Well I don't know the mechanics of it all I know is if the application crashes the record lock is automaticall removed, probably it is related the users session. I have never had a user call sto say they couldn't get back in ... that may be due to the fact my apps never crash :) On Wed, 9 Dec

Re: How do I keep an operator from logging in twice from the same computer

I KNEW I was missing some detail...crashless apps! Perfect! I'm gonna put that in all my apps, right now! Thanks! :) Mike Copeland Stephen Weeks wrote: Well I don't know the mechanics of it all I know is if the application crashes the record lock is automaticall removed, probably it is

Re: How do I keep an operator from logging in twice from the same computer

Sounds reasonable, but how does the "/...in the event of a crash the lock is automatically removed./" part work? Thanks for any enlightenment. Mike Copeland mbsoftwaresoluti...@mbsoftwaresolutions.com wrote: On 2015-09-17 03:32, Stephen Weeks wrote: I have a user table and when the user

Re: How do I keep an operator from logging in twice from the same computer

On 2015-09-17 03:32, Stephen Weeks wrote: I have a user table and when the user logs in it puts a lock on his/her record and removes it when the user exits the syetem, in the event of a crash the lock is automatically removed. That seems like the most logical way to easily accomplish the

Re: How do I keep an operator from logging in twice from the same computer

I'm thinking there's gotta be one last "desperation call" to a stored procedure with the person's key in an attempt to "unlock this dude's record" but of course, if you've lost connection to the database (and it can't reconnect), I'm guessing that user would have to call the HelpDesk to say

Re: How do I keep an operator from logging in twice from the same computer

> -Original Message- > From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of > Stephen Russell > Sent: Wednesday, September 16, 2015 2:34 PM > To: profoxt...@leafe.com > Subject: Re: How do I keep an operator from logging in twice from the > same computer >

Re: How do I keep an operator from logging in twice from the same computer

t; > -Original Message- > > From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of > > Stephen Russell > > Sent: Wednesday, September 16, 2015 2:34 PM > > To: profoxt...@leafe.com > > Subject: Re: How do I keep an operator from loggin

Re: How do I keep an operator from logging in twice from the same computer

Hi All, Something you might want to keep in mind is terminal services (and Citrix, 2X etc). There may be several people running your app on the same server from different sessions. I'm seeing this more and more these days. -- Paul ___ Post Messages

Re: How do I keep an operator from logging in twice from the same computer

There's a load of stuff about this on the FoxWiki. If you log in and search for "mutex" you'll find a lot. Laurie On 17 September 2015 at 11:46, Paul Hill wrote: > Hi All, > > Something you might want to keep in mind is terminal services (and > Citrix, 2X etc). > There

How do I keep an operator from logging in twice from the same computer

I could create a flag but it will still be there if he crashes and tries to get back in. Is there not a way to check to see if an exe is running? Wes Wilson, President ERW Custom Programming, Inc. Crescent Lake Plaza 5459  Elizabeth Lake Rd. Waterford, MI 48327 (248) 683-4182

Re: How do I keep an operator from logging in twice from the same computer

Create a table in the database and have the application attempt to use it EXCLUSIVELY (in a TRY... CATCH or with an ON ERROR). When the app crashes, in 99.999% of the cases, the exclusive lock goes away by itself. Yes, there is a way to check if the EXE is running, but that's more work. On

RE: How do I keep an operator from logging in twice from the same computer

: Wednesday, September 16, 2015 3:36 PM To: profoxt...@leafe.com Subject: RE: How do I keep an operator from logging in twice from the same computer Stephen - that's very interesting. When you gave the link - and I checked it out - it wasn't quite clear where you run this command. But, I guessed

Re: How do I keep an operator from logging in twice from the same computer

Yes, there is a way, or even more than one, You can use a Windows Semaphore, that is automatically released if the app crashes. As a way for knowing if an exe is running (even if crashed but not released from memory), you can query WMI for active process names. Regards.- 2015-09-16 20:17

Re: How do I keep an operator from logging in twice from the same computer

On Wed, Sep 16, 2015 at 1:17 PM, Wes Wilson wrote: > I could create a flag but it will still be there if he crashes and tries > to get back in. > Is there not a way to check to see if an exe is running? > --- I would query the running applications myself.

RE: How do I keep an operator from logging in twice from the same computer

this way. Very Cool! -K- -Original Message- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Stephen Russell Sent: Wednesday, September 16, 2015 2:34 PM To: profoxt...@leafe.com Subject: Re: How do I keep an operator from logging in twice from the same computer On Wed, Sep

RE: [NF] Turned on touter logging in a 10-computer office

are. --- On Wed, 12/1/10, Jarvis, Matthew mat...@mckweb.com wrote: From: Jarvis, Matthew mat...@mckweb.com Subject: RE: [NF] Turned on touter logging in a 10-computer office To: profox@leafe.com Date: Wednesday, December 1, 2010, 7:26 PM -Original Message- From: profoxtech

RE: [NF] Turned on touter logging in a 10-computer office

I'm not sure what the deal is. If you went to porno sites all day you wouldn't get this many viruses and spyware. --- On Thu, 12/2/10, Alan Bourke alanpbou...@fastmail.fm wrote: From: Alan Bourke alanpbou...@fastmail.fm Subject: RE: [NF] Turned on touter logging in a 10-computer office

Re: [NF] Turned on touter logging in a 10-computer office

Michael Madigan wrote: I'm not sure what the deal is. If you went to porno sites all day you wouldn't get this many viruses and spyware. Hi Michael, Have you researched that or is that something we have to do yet? -- Regards, Pete http://pete-theisen.com/ http://elect-pete-theisen.com/

Re: [NF] Turned on touter logging in a 10-computer office

On Thu, Dec 2, 2010 at 4:43 PM, Pete Theisen petethei...@verizon.net wrote: Michael Madigan wrote: I'm not sure what the deal is.  If you went to porno sites all day you wouldn't get this many viruses and spyware. Hi Michael, Have you researched that or is that something we have to do yet?

[NF] Turned on touter logging in a 10-computer office

Holy Cow. No wonder this guy is always tight on money. Looks like some of his employees are surfing the internet all day. Unfortunately his biggest offender is his kid. This is the one whose computer is filled with malware. Well it's time for some tough love and a shut down of her port

RE: [NF] Turned on touter logging in a 10-computer office

-Original Message- From: profoxtech-boun...@leafe.com [mailto:profoxtech-boun...@leafe.com] On Behalf Of Michael Madigan Sent: Wednesday, December 01, 2010 1:10 PM To: profoxt...@leafe.com Subject: [NF] Turned on touter logging in a 10-computer office Holy Cow. No wonder

RE: [NF] Turned on touter logging in a 10-computer office

...@mckweb.com Subject: RE: [NF] Turned on touter logging in a 10-computer office To: profox@leafe.com Date: Wednesday, December 1, 2010, 7:15 PM -Original Message- From: profoxtech-boun...@leafe.com [mailto:profoxtech-boun...@leafe.com] On Behalf Of Michael Madigan Sent: Wednesday

RE: [NF] Turned on touter logging in a 10-computer office

-Original Message- From: profoxtech-boun...@leafe.com [mailto:profoxtech-boun...@leafe.com] On Behalf Of Michael Madigan Sent: Wednesday, December 01, 2010 4:21 PM To: profoxt...@leafe.com Subject: RE: [NF] Turned on touter logging in a 10-computer office Assuming they can do

RE: [NF] Turned on touter logging in a 10-computer office

logging in a 10-computer office To: profox@leafe.com Date: Wednesday, December 1, 2010, 7:26 PM -Original Message- From: profoxtech-boun...@leafe.com [mailto:profoxtech-boun...@leafe.com] On Behalf Of Michael Madigan Sent: Wednesday, December 01, 2010 4:21 PM To: profoxt

Re: DBC Logging

Alan Bourke wrote: I need something to apply insert, delete and update triggers to a number of tables automatically, with a view to logging changes to the data. An ex-colleague was telling me about a solution for this a while back, which I believe was in the public domain, maybe off UT

DBC Logging

I need something to apply insert, delete and update triggers to a number of tables automatically, with a view to logging changes to the data. An ex-colleague was telling me about a solution for this a while back, which I believe was in the public domain, maybe off UT or similar. Does this ring

Re: DBC Logging

Thanks - it was more a ready-rolled utility to do this and apply it to like 150 tables in one go! -- Alan Bourke [EMAIL PROTECTED] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free

Re: DBC Logging

Alan Bourke wrote: Thanks - it was more a ready-rolled utility to do this and apply it to like 150 tables in one go! Something like this? OPEN DATABASE MyDBC =ADBOBJECTS(aTables, TABLE) FOR nI = 1 to ALEN(aTables) cTable = aTables[nI] CREATE TRIGGER ON cTable FOR UPDATE AS

Re: DBC Logging

Yes, that's the sort of thing. Thanks Brian! -- Alan Bourke [EMAIL PROTECTED] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list:

Re: DBC Logging

Alan Bourke wrote: I need something to apply insert, delete and update triggers to a number of tables automatically, with a view to logging changes to the data. An ex-colleague was telling me about a solution for this a while back, which I believe was in the public domain, maybe off UT

RE: Logging changes in FPW 2.6

-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hal Kaplan Sent: Wednesday, June 14, 2006 14:03 To: ProFox Email List Subject: RE: Logging changes in FPW 2.6 I keep that type of information right in the data dbf. I use two fields, Effective Terminate