Hi All,

Is there any information available on a simple canned ASP hit counter I could quickly throw up on site.

Regards,

Cos

Hello,

We dont have a specific counter that we recommend, but I looked on the web and found the following link that may be helpful, http://www.asp-counter.co.uk/simple-text-fso.asp

Basically you have a text file in your site that stores the counter. Using FSO (File System Object) you open the text file, read the number out of it, add 1, display the number on the page and then overwrite the number in the text file with the new number. The like I provided supplies code for this.

The only change is that in Set bwoFile = bwoFSO.OpenTextFile("C:\wwwroot\count.txt") you need to specify the location to the text file in your websites folder. You may also need to give the file write permissions, which you can do through the control panel.

I hope that helps.

-Alan

Hi Alan, your link doesn't seem to work anymore, do you have another one for it?

Thanks

Let me try to post what worked for me.
http://www.asp-counter.co.uk/simple-text-fso.asp

Sorry about that. It seems that the post added the period at the end of the sentence to the url. I edited the post so the link should work. Thanks!

Hi Alan,

I'm working with someone who purchased a site package that includes counts of total page views etc as session variables, and the site keeps having related problems. Writing counts to any file, it would seem, would take pressure off of memory to track all of that.

Are there any "gotchas" associated with writing to this text file each time a page loads?

What would be the advantages of using this method vs storing in a SQL table? I was thinking of a simple stored procedure that executes on each page load.

Here would be the table ... just doing quick design for example ...

Fields:
TotalPageViewDate
TotalPageViewCount

The table will contain at most a single record at all times, not one per hit or per day. Those things are best tracked thru software designed expressly for that purpose

Let's say that we start out like this.




The next time a page is visited today, the record would become:



The first time a page is visited tomorrow, the record would become:



And then the ASP code would extract & display those values.

Is that simplifying things too much? I don't want to create a new problem to replace the current one, and bog down the server in a different manner or slow down SQL Server with all those hits ... I'm not ServerDude, so I wanted to get the 411 from more learned minds than my own on the system impact

Thanks in advance,
Bryant

Bryant... that's a perfect example. I've used methods such as that and never had a problem. Keep in mind what timezone you want to be tracking in and what timezone you're sitting in though... because that can mess up the count for some people. Remember to just adjust the time correctly.

Thanks, Josh!

For the time zone thing, I'm going to let all time determinations be driven by SQL Server, which is same timezone as the site server. The stored procedure will contain the GETDATE() info, rather than an argument of the current date/time being passed by the ASP code. Is that what you meant?

Another two brief questions ...

- What about using global.asa & session variables to track number of folks currently online ... does this negatively impact performance? That's how it is currently operating, but I don't think this is where the problems lie. I don't want to jeopardize what hopefully will be a high traffic site with constant memory problems.

- Can you let me know what you think of this routine, which displays "Members Online" by name? http://www.codeproject.com/asp/user_logtime.asp Don't worry, I'm not planning to use Access for this I think much of the problem we're having now is that the application is also storing in memory usernames of current members online as part of an object named WhosOn. I was thinking this could be modified for SQL Server. This is all I've found so far, but I have not yet begun to Google

Thanks,
Bryant

There are no performance related issues for using global.asa(x) do do such things. However, in the past (because I'm very memory concious), what I've done is just include a LastLoggedOn datetime field in a table that relates to the last time a user is logged on. Then, just check to see who's online in the last 15 mins or so. Things get funny using session to track stuff like that because the session will be tracked 10-20 mins after the user is actually gone... so if anything it's less reliable as far as accuracy goes.

And what I just said above can be used to not only show how many people are "online" but who's online too

Then, on pageloads, just have a function update the LastLoggedOn field Easy stuff.

And for the sake of the world... dont' EVER use access. SQL is nice if you can afford it or have access to it, but here lately I've started using MySQL for my ASP.NET applications and I must confess that it works REALLY well with very minimal changes to anything. And you don't have to go thru any of that slow and chumpy ODBC stuff... there's a .NET connector taht works REALLY welll... so far, except for the namespace stuff, the only thing I've had to change is my query parameters... instead of using "@" like "SELECT * FROM Table WHERE This=@This" I just use "?".... very nice with minimal changes.

Access has its part for desktop applications, and for very simple web purposes (read-only querying) on low-traffic sites. It's also great as a front-end for SQL Server databases. I have had fantastic success with it in those situations. But I agree, there's a purpose for each tool out there, and for tracking users currently online Access would not be the choice. (Heheheh, I said tool )

Bryant

That is a HORRIFIC mistake that alot of people make... if SQL you should use queries/commands, or enterprise manager, or something equivilent to it. Access is a poor choice for a frontend.

By "front-end," I mean an Access ADP or MDB connecting to a SQL database, and working with data thru Access forms, reports, and VBA code, primarily thru executing stored procedures on the server. Local XML files or tables are created to minimize server traffic. This provides a familiar interface for the data, and Access' reporting capabilities ... but I never use this as a means of designing tables or stored procedures.

Is that still objectionable? If so, I'd be interested in learning why.

Bryant