Is it possible to create a batch-file which opens firefox, runs a website and then closes firefox again?
Something like:
@echo off
start firefox http
If you just want to call a page on a website that already exists, the following is an easy way to accomplish it.
Option Explicit
On Error Resume Next
' Declare our vars
Dim objWinHttp, strURL
' Request URL from 1st Command Line Argument. This is
' a nice option so you can use the same file to
' schedule any number of differnet scripts just by
' changing the command line parameter.
'strURL = WScript.Arguments(0)
' Could also hard code if you want:
strURL = "http://www.example.com/myscript.asp"
' For more WinHTTP v5.0 info, including where to get
' the component, see our HTTP sample:
' http://www.asp101.com/samples/winhttp5.asp
Set objWinHttp = CreateObject("WinHttp.WinHttpRequest.5")
objWinHttp.Open "GET", strURL
objWinHttp.Send
' Get the Status and compare it to the expected 200
' which is the code for a successful HTTP request:
' http://www.asp101.com/resources/httpcodes.asp
If objWinHttp.Status <> 200 Then
' If it's not 200 we throw an error... we'll
' check for it and others later.
Err.Raise 1, "HttpRequester", "Invalid HTTP Response Code"
End If
' Since in this example I could really care less about
' what's returned, I never even check it, but in
' general checking for some expected text or some sort
' of status result from the ASP script would be a good
' idea. Use objWinHttp.ResponseText
Set objWinHttp = Nothing
If Err.Number <> 0 Then
' Something has gone wrong... do whatever is
' appropriate for your given situation... I'm
' emailing someone:
Dim objMessage
Set objMessage = Server.CreateObject("CDO.Message")
objMessage.To = "you@example.com"
objMessage.From = "cron job <cron@example.com>"
objMessage.Subject = "An Error Has Occurred in a " _
& "Scheduled Task"
objMessage.TextBody = "Error #: " & Err.Number & vbCrLf _
& "From: " & Err.Source & vbCrLf _
& "Desc: " & Err.Description & vbCrLf _
& "Time: " & Now()
objMessage.Send
Set objMessage = Nothing
End If
Either change strURL
to your script or uncomment the line strURL = WScript.Arguments(0)
and pass the url as a parameter. Put it in Task scheduler with cscript.exe
.
This is how I do all my ASP based scheduled tasks so I can test that much easier, you might want to lock your script down to only accepting access via the server's IP to make sure it's not called by a bot.
Edit: For clarity.
Adapted from an article I wrote on aspfaq.com years ago.
Use the AT command and Windows Scripting Host (or the more rudimentary task scheduler) to schedule a VBS file at certain intervals.
First, change the ASP to a VBS file. This is accomplished by (1) changing the extension to VBS; (2) changing all Server.CreateObject calls to CreateObject; and, (3) removing all <%%>
delimiters and any browser-destined code (for example, response.write statement or client-side HTML). I didn't run into any further complications, but YMMV.
You store the VBS file in the filesystem, and use the AT command to schedule it (this actually schedules its execution with Windows's schedule service). At a command prompt, you can use AT by itself to see a list of tasks currently in the schedule. You can use AT /? to find out all its syntax possibilities.
For example, to get a file to run every weekday at 9:00 am, I launch this batch file (the first line clears existing entries):
at /delete /y
at 9:00 /every:m,t,w,th,f d:\net\shared\getdata.vbs
Notice there is no web server involved; the file is accessed directly through the file system. Once I got over the "a user has to be logged in" and "the tasks have to be reset when rebooted" hurdles (both of which I believe are problems with the particular machine that is not under our control), all has been running fine for me.
For an example of using WSH, CDONTS and the Task Scheduler to send out e-mails on a regular basis, see KB #221495.
If all you are doing is database work in SQL Server, you might consider using a job. This will allow you to keep all the processing of the job within your database, and prevent the complications associated with multiple systems, connections, and adapting ASP code to be non-ASP-like in behavior.