I have been given a project originally written in VMS C. It is
extensive code, with a number of complex algorithms. It also
accesses
an Oracle database via Embedded SQL.

The code is to be ported to a Windows Server 2003 environment. The
database will be ported to Microsoft SQL Server.


I have a couple of choices:


The most ideal choice from a long-term standpoint is to convert the
code to C# and use OLEDB to access the database. Everythings going
to
C#, as far as I can see. I have also used OLEDB in VB applications
so
I am familiar with it. The downside is that there is no "nice"
conversion from unmanaged C code to C#. I see a number of nasty,
unknown gotchas that could pop up. Even if I find a good conversion
package, there would be major work ahead.


The second choice is to convert to C++ and use the standard ODBC
classes (CDatabase, CRecordset) to access the database. This is
somewhat easier, as more of the original code could be carried over.
The downside here is that I'm left with an application that uses a
platform and functions that will be outdated sooner. From what I can
see, ODBC is falling slowly out of use. At least most of the
articles
I see on the internet are at least a year old, most are older. I
could be wrong, though.


The operating constraints for the project are that I have some extra
time in for R&D, but not a huge amount. The same applies to the
budget. The project manager does not want to risk getting bogged
down
trying to get the newest software to work on the old code. Having
converted one project from VB 6.0 to VB.NET a few years back, I can
testify that what looks like a fairly simple conversion usually
isn't.


I would appreciate any recommendations and/or input as to which way I
should go.

My gut tells me that you should simply recompile the C using just the Microsoft C compiler, and not even bother trying to convert to
C++ on the first pass. Concentrate your efforts on the SQL interface. If there is time afterwards, consider touching up the key
parts to C++, and possibly even using the ATL OLE DB Templates. (cf. http://msdn2.microsoft.com/en-us/library/8k76sd16(VS.80).aspx)

Nobody is going to thank you for updating to C#/SQLAdapter if you blow your schedule or your budget. Get it running under Windows
Server 2003 is the first priority.

(Just my gut feel.)

Brian

"fdmaxey" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
>I have been given a project originally written in VMS C. It is
> extensive code, with a number of complex algorithms. It also
> accesses
> an Oracle database via Embedded SQL.
>
> The code is to be ported to a Windows Server 2003 environment. The
> database will be ported to Microsoft SQL Server.
>
>
> I have a couple of choices:
>
>
> The most ideal choice from a long-term standpoint is to convert the
> code to C# and use OLEDB to access the database. Everythings going
> to
> C#, as far as I can see. I have also used OLEDB in VB applications
> so
> I am familiar with it. The downside is that there is no "nice"
> conversion from unmanaged C code to C#. I see a number of nasty,
> unknown gotchas that could pop up. Even if I find a good conversion
> package, there would be major work ahead.
>
>
> The second choice is to convert to C++ and use the standard ODBC
> classes (CDatabase, CRecordset) to access the database. This is
> somewhat easier, as more of the original code could be carried over.
> The downside here is that I'm left with an application that uses a
> platform and functions that will be outdated sooner. From what I can
> see, ODBC is falling slowly out of use. At least most of the
> articles
> I see on the internet are at least a year old, most are older. I
> could be wrong, though.
>
>
> The operating constraints for the project are that I have some extra
> time in for R&D, but not a huge amount. The same applies to the
> budget. The project manager does not want to risk getting bogged
> down
> trying to get the newest software to work on the old code. Having
> converted one project from VB 6.0 to VB.NET a few years back, I can
> testify that what looks like a fairly simple conversion usually
> isn't.
>
>
> I would appreciate any recommendations and/or input as to which way I
> should go.
>

fdmaxey wrote:
> I have been given a project originally written in VMS C. It is
> extensive code, with a number of complex algorithms. It also
> accesses
> an Oracle database via Embedded SQL.
>
> The code is to be ported to a Windows Server 2003 environment. The
> database will be ported to Microsoft SQL Server.
>
> I have a couple of choices:
>
> The most ideal choice from a long-term standpoint is to convert the
> code to C# and use OLEDB to access the database.

If you go .NET you will not want to use OLE DB but instead use
the .NET SqlClient.

> Everythings going
> to
> C#, as far as I can see. I have also used OLEDB in VB applications
> so
> I am familiar with it. The downside is that there is no "nice"
> conversion from unmanaged C code to C#. I see a number of nasty,
> unknown gotchas that could pop up. Even if I find a good conversion
> package, there would be major work ahead.

I think that is correct.

> The second choice is to convert to C++ and use the standard ODBC
> classes (CDatabase, CRecordset) to access the database. This is
> somewhat easier, as more of the original code could be carried over.
> The downside here is that I'm left with an application that uses a
> platform and functions that will be outdated sooner.

A third option would be to go for managed C++ (C++/CLI is the name
this month I think) as language and .NET SqlClient as database
API.

It should be easier to port to C++ than to C#. You get a good
database API.

You can migrated to C# gradually over the coming years.

Arne

fdmaxey wrote:
> I have been given a project originally written in VMS C. It is
> extensive code, with a number of complex algorithms. It also
> accesses
> an Oracle database via Embedded SQL.
>
> The code is to be ported to a Windows Server 2003 environment. The
> database will be ported to Microsoft SQL Server.
>
>
> I have a couple of choices:
>
>
> The most ideal choice from a long-term standpoint is to convert the
> code to C# and use OLEDB to access the database. Everythings going
> to
> C#, as far as I can see. I have also used OLEDB in VB applications
> so
> I am familiar with it. The downside is that there is no "nice"
> conversion from unmanaged C code to C#. I see a number of nasty,
> unknown gotchas that could pop up. Even if I find a good conversion
> package, there would be major work ahead.
>
>
> The second choice is to convert to C++ and use the standard ODBC
> classes (CDatabase, CRecordset) to access the database. This is
> somewhat easier, as more of the original code could be carried over.
> The downside here is that I'm left with an application that uses a
> platform and functions that will be outdated sooner. From what I can
> see, ODBC is falling slowly out of use. At least most of the
> articles
> I see on the internet are at least a year old, most are older. I
> could be wrong, though.
>
>
> The operating constraints for the project are that I have some extra
> time in for R&D, but not a huge amount. The same applies to the
> budget. The project manager does not want to risk getting bogged
> down
> trying to get the newest software to work on the old code. Having
> converted one project from VB 6.0 to VB.NET a few years back, I can
> testify that what looks like a fairly simple conversion usually
> isn't.
>
>
> I would appreciate any recommendations and/or input as to which way I
> should go.

I have to agree with Brian Muth here - get the C code to compile as C on
Windows first, then deal with the database connections. To interface with
SQL server, you have two or three options that might make sense:

1. Continue to use embedded SQL. I'm not certain, but I think this might
actually still be supported by SQL 2005. It was part of the SQL standard
afterall.
2. Use OLE-DB or even ADO directly from C(++) to interface with SQL server.
3. Use the SQL Native Client directly from C(++) to interface with SQL
server.
4. Use C++/CLI to build a native/managed bridge between your C code and
ADO.NET to access SQL server.

The quantity of embedded SQL will likely influence your choice. For options
2-4 above, you may want to or need to get the code to compile as C++ first
(which is not to say that you need to factor it into classes, etc - just get
it to compile as pure procedural C++).

Is the SQL connection your only challence? Frequently when porting
applications from other OS's, basic differences in process model (threads,
signals, fork/join, etc) end up being the big challenges due to the design
changes they may require.

-cd

If you are interested in outside help, Datatek, Inc offers an
automated C/C++ to C# conversion service. We can produce nice clean C#
code and we guarantee our results. Feel free to give me a call or
shoot me an email if you would like more information.

Charles Churchill
Account Executive
Datatek, Inc.
800 536-4835 ext. 145
1 919 425-3145 (international)
(E-Mail Removed)