Extended Stored Procedure

Good morning,
We are porting a legacy VB6 user interface application that stores data in
binary text files to SQL Server 2000 and C#.
The VB6 user interface hooks into backend C/C++ dll's to pass VB6 "Type"
data into the C code that writes to the binary files.
We have to preserve this strategy of writing data to binary files because a
massive C dll library uses them to analyze the data.
What I would like to do is store the data in a normalized SQL database and
then use Extended Stored Procedures (ESP) to hook into the C functions that
write the binary files.
This would require selecting a row of data from a SQL table and then passing
it to the ESP C function in a way that mimics the VB6 Type datatype. Really
the C is looking for a pointer to the beginning of the Type data.
Any thoughts/advice greatly appreciated!
Thank you
jmattSQL Server is not an application development tool. Processing data one row
at a time and calling C functions would be best implemented on the
application side rather than from the database.
"jmatt" <jmatt@.discussions.microsoft.com> wrote in message
news:8E82603C-AA1F-462A-AEA4-7EDC103E5F45@.microsoft.com...
> Good morning,
> We are porting a legacy VB6 user interface application that stores data in
> binary text files to SQL Server 2000 and C#.
> The VB6 user interface hooks into backend C/C++ dll's to pass VB6 "Type"
> data into the C code that writes to the binary files.
> We have to preserve this strategy of writing data to binary files because
> a
> massive C dll library uses them to analyze the data.
> What I would like to do is store the data in a normalized SQL database and
> then use Extended Stored Procedures (ESP) to hook into the C functions
> that
> write the binary files.
> This would require selecting a row of data from a SQL table and then
> passing
> it to the ESP C function in a way that mimics the VB6 Type datatype.
> Really
> the C is looking for a pointer to the beginning of the Type data.
> Any thoughts/advice greatly appreciated!
>
> Thank you
> jmatt|||I understand your point. It just seems so direct and efficient to go from
table to file.
Thanks!
jmatt
"JT" wrote:

> SQL Server is not an application development tool. Processing data one row
> at a time and calling C functions would be best implemented on the
> application side rather than from the database.
> "jmatt" <jmatt@.discussions.microsoft.com> wrote in message
> news:8E82603C-AA1F-462A-AEA4-7EDC103E5F45@.microsoft.com...
>
>|||> SQL Server is not an application development tool.
Not sure I totally agree with that. SQL2005 is great application server
environment. The lines are not dark any more, they are shades of grey.
This kind of thing would be ~easy to do in sql2005 clr.
William|||William,
Any ideas on how I would pass data to the C function as a parameter in ESP
so that it would mimic VB6 Type data? Would the result of a simple SELECT b
e
a start?
jmatt
"William Stacey [MVP]" wrote:

> Not sure I totally agree with that. SQL2005 is great application server
> environment. The lines are not dark any more, they are shades of grey.
> This kind of thing would be ~easy to do in sql2005 clr.
> --
> William
>
>|||You have SQL2005? If not, then I can't help.
If so, I would rewrite the function in C# and just call from a SqlUDF then
you can use the power of .Net and IO classes.
You could probably also call c dll from SqlUDF like you would call a win32
function, by defining it first.
William Stacey [MVP]
"jmatt" <jmatt@.discussions.microsoft.com> wrote in message
news:371399B9-B337-4F6F-AECD-89CFBB626DA0@.microsoft.com...
> William,
> Any ideas on how I would pass data to the C function as a parameter in ESP
> so that it would mimic VB6 Type data? Would the result of a simple SELECT
> be
> a start?
> jmatt
> "William Stacey [MVP]" wrote:
>