Results 1 to 2 of 2
  1. #1
    Join Date
    Jan 2004
    Posts
    1

    Question Unanswered: Calling a VB exe from a stored procedure

    Can someone tell me a straightforward way to call a VB app (that accepts command line arguments) from a stored procedure.

    I have got it to work by using xp_cmdshell, but in practice, the security constraints here prevent using this. Our DBAs don't want to set the proxy account required for a non-sysadmin user to eexecute xp_cmdshell.

    I know that writing an extended SP invoking a C++ dll would be the cleanest solution. However I don't have the knowledge to do that.

    Any ideas?

    Thanks

  2. #2
    Join Date
    Jul 2002
    Posts
    58

    Re: Calling a VB exe from a stored procedure

    Originally posted by mtnlvrs
    Can someone tell me a straightforward way to call a VB app (that accepts command line arguments) from a stored procedure.

    I have got it to work by using xp_cmdshell, but in practice, the security constraints here prevent using this. Our DBAs don't want to set the proxy account required for a non-sysadmin user to eexecute xp_cmdshell.

    I know that writing an extended SP invoking a C++ dll would be the cleanest solution. However I don't have the knowledge to do that.

    Any ideas?

    Thanks

    I think your opening post eliminated the only two ways to do this (and actually, there's only one, since XP_CMDSHELL is just a very simple extended proc DLL)

    Actually, just straight C will do for the DLL. It's not as hard as you seem to think. On the other hand, you gotta be sure of that code, since you'll be running in the engines address space. Just be sure to clean up everything, check your buffer lengths, and initialize all your pointers and it will work just fine. But I'm fairly certain extended procs are the only way to 'step outside' of what TSQL is capable of, ie run your VB code, and retain control flow.

    Now, if it's OK for your VB code to run asynchronously, you could always make it step in a SQL Agent Job, and kick it off in a stored proc by executing msdb..sp_start_job, but you won't be able to return anything and your stored proc won't wait on the job to finish. And you'll have concurrency issues, as only one copy of a SQL Agent job can run at a time.
    Last edited by Steve Duncan; 01-31-04 at 20:06.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •