Passing parameter to VB from SQL Server 7.0

Very new VB user here.

I would appreciate any ideas or suggestions about the following situation.

We are setting up a SQL Server routine that will run and constantly poll a directory. As soon as something is found in that directory, we need SQL Server to run a VB program and pass it at least one parameter for VB to use in running a process that will update several tables.

What needs to be done on the VB side to be able to accept a parameter passed to it, either from SQL Server or possibly just from the command line ?

I know nothing about the SQL side at this time, but I am guessing it would have a command similar to "run vbprog parameter".

Thanks a lot for any feedback.

I'd have to search for that too, but why not let the VB prog poll the directory and do something when the file is there?

I'd go with same reply as CrazyD.

How many times a day do you need to upload the Data? I have a similar requirement (I think) to what you have, but the data only needs loading to the Database once a day. Rather than have the VB sitting there polling all day - using resources - I use a schedular to start the VB app early morning. The VB app sits there until the data arrives in the relevant folder, processes the stuff and toddles off until the schedular starts it again.

Forgive me if I sound ignorant of what all is going on, but what has been explained to me is this.

We will be receiving requests (all day) via e-mail that will place a value in a field within a table. When that field receives a value (indicating that an e-mail has been received), a trigger will be activated that will call the VB program which will validate the information received in the e-mail against a DB2 table.

I am just wondering if it is possible to pass a value into a VB program from the SQL Server.

Our analysts have been considering running the whole process from a VB app if we cannot find some way to pass the information. I have written applications that will poll directories at different time intervals, so that would not be a problem to set up.

Again, thanks for any ideas/suggestions.

As part of your trigger you could write data into a (as yet undefined) table. Your VB program could read that table, do what it needs to do and then delete the item from the table (and, if you really want to be safe, write the record to another table that represents work finished).

Excellent suggestion. I'll run it by the team in the morning and see what they think.

Thanks.

Beauty of the solution is that the VB program can run continuously. It just keeps reading the trigger table, only taking action when an entry shows up...