Hi Rick,

Based on our conversations around my (thankfully) solved mystery I'd like to get the server name into the standard wwrequestlog table. Before I go off and roll my own I know you mentioned possibly doing something like that. Did I interpret that correctly or should I do my own sub-class/override?

TIA

I'm still debating this. Main reason being that for most people the machine name is not a thing because you're running on a single machine and if you're using FoxPro data you're unlikely to be sharing request log data across machines.

And... more importantly this requires another field with more data in the request log. The machine name does show up in the request data and the log viewer can be changed to show that without much overhead.

+++ Rick ---

Understood. While I can't be the only one running multiple servers I do understand that changing the logging table structure has its challenges for existing installations.

Personally I don't trust DBFs to keep up with my level of traffic, and the ability to do analysis, etc is just much more robust in a SQL DB. I rolled over the SQL DB on that Saturday when things fell over, less than 10 days ago, and I've got 1.7 million requests and 600k sessions since then. I'm working through a strategy to roll over my logging DB on a regular basis.

IIRC requestdata, servervars, etc are only populated if more than minimal logging is enabled, and running at level 2 or 3 in production is not recommended. So I can't count on having the machine name in wwRequestLog unless I'm willing to add that overhead. I'll continue to mull over my options.

PMFJI but I got myself into a mess in the past by messing with the usersecurity tables - only because of the hassles when new webconnect updates changed the structure (mind you - this was with a project that's been maintained for about 25 years).

I'd suggest using a separate related table to include the additional info - joined by UserSecurity.PK, perhaps.

You've also got a few memo fields in the UserSecurity table (Notes, Properties, etc). Some of my clients have taken to adding info into one of those in JSON format in order to hold more than one piece of information.

HTH

That's why you need to read the Breaking Changes section for updates 😄

True - but the less I mess with that particular table for revisions, the happier I am.

I try not to change those tables as much as possible but sometimes changes are prudent to make. The User Security table changes were made when the manager was introduced and that required extra fields.

Adding extra tables would make things even more complex, so if changes are made making them in the base table is better at the framework level. If you want to add customizations and put them into separate tables for custom apps that's a good way to separate out the differences but that'll be up to you to implement and maintain the db relationship.

+++ Rick ---

I appreciate the participation, Michael. 😃

Just to be clear about this, I'm referring to the wwRequestLog table, not UserSecurity. I've already subclassed UserSecurity to my heart's content to support a SQL backend and add a column that suits my needs.

But the session and request logging go to the heart of the framework, and while it would make my life easier if it was handled at the framework level, that cost-benefit ratio has to work for Rick particularly if it induces a Breaking Change ((R) West Wind Technologies).

So my choices until he makes that decision are basically sub-class the framework's logging methods, or use an alternate logging mechanism to track which of my IIS servers took the request.

Oh - 'Nevermind'...