I am currently making the jump from VB6 to C#. We have a login prompt
that returns an ADO connection. Eventually I will have to re-write this
login prompt in C#, but for now I have to use it for a C# program that
needs to be finished soon. Basically, I call the prompt, get the ADO
connection, create an SQL connection, and try to set the
SQLConnection's ConnectionString to the Adodb.connection's connection
string, so that I can use the SQLConnection throughout the project.
This is where I get the error.

The line of code:

SQLConn.ConnectionString = AdoConn.ConnectionString;

raises ArgumentException and I am not sure why.

Can anyone clarify?

Thanks,
Mike

Michael - what does the ConnectionString of the AdoConn look like?
<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I am currently making the jump from VB6 to C#. We have a login prompt
> that returns an ADO connection. Eventually I will have to re-write this
> login prompt in C#, but for now I have to use it for a C# program that
> needs to be finished soon. Basically, I call the prompt, get the ADO
> connection, create an SQL connection, and try to set the
> SQLConnection's ConnectionString to the Adodb.connection's connection
> string, so that I can use the SQLConnection throughout the project.
> This is where I get the error.
>
> The line of code:
>
> SQLConn.ConnectionString = AdoConn.ConnectionString;
>
> raises ArgumentException and I am not sure why.
>
> Can anyone clarify?
>
> Thanks,
> Mike
>

Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security
Info=False;Initial Catalog=master;Data Source=PANSQLPROD;Use Procedure
for Prepare=1;Auto Translate=True;Packet Size=4096;Application
Name=SBSchedMgr 1.0;Workstation ID=MSUAREZ-XP;Use Encryption for
Data=False;Tag with column collation when possible=False

Yah, that's not going to work. Among other things, 'Provider' isn't
supported so this will always blow up as stands.
<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security
> Info=False;Initial Catalog=master;Data Source=PANSQLPROD;Use Procedure
> for Prepare=1;Auto Translate=True;Packet Size=4096;Application
> Name=SBSchedMgr 1.0;Workstation ID=MSUAREZ-XP;Use Encryption for
> Data=False;Tag with column collation when possible=False
>

So I guess what you're saying is, I can't just simply set the value of
an SqlConnection's ConnectionString to the value of an
Adodb.Connection's ConnectionString because they are built differently.
The fact that an ArgumentException got thrown didn't really convey what
the problem was.

Thanks for the response though.

I guess I will just use the old ADO connection for this project, until
i write a new login prompt in C# using the SqlConnection.

Yes, the connection strings are different so that won't work directly.
<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> So I guess what you're saying is, I can't just simply set the value of
> an SqlConnection's ConnectionString to the value of an
> Adodb.Connection's ConnectionString because they are built differently.
> The fact that an ArgumentException got thrown didn't really convey what
> the problem was.
>
> Thanks for the response though.
>
> I guess I will just use the old ADO connection for this project, until
> i write a new login prompt in C# using the SqlConnection.
>

Ah, there are more differences than similarities between ADO classic
(COM-based) and ADO.NET. I suggest that you assume that they are different
from the beginning--any similarities you find along the way will be a nice
surprise.
I discuss the (copious) differences between ADO classic and ADO.NET in my
book (ADO.NET Examples and Best Practices).

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> So I guess what you're saying is, I can't just simply set the value of
> an SqlConnection's ConnectionString to the value of an
> Adodb.Connection's ConnectionString because they are built differently.
> The fact that an ArgumentException got thrown didn't really convey what
> the problem was.
>
> Thanks for the response though.
>
> I guess I will just use the old ADO connection for this project, until
> i write a new login prompt in C# using the SqlConnection.
>

I don't know where I would have been without Bill's book - it's a lifesaver
in more ways than one.
"William (Bill) Vaughn" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Ah, there are more differences than similarities between ADO classic
> (COM-based) and ADO.NET. I suggest that you assume that they are different
> from the beginning--any similarities you find along the way will be a nice
> surprise.
> I discuss the (copious) differences between ADO classic and ADO.NET in my
> book (ADO.NET Examples and Best Practices).
>
> --
> ____________________________________
> William (Bill) Vaughn
> Author, Mentor, Consultant
> Microsoft MVP
> INETA Speaker
> www.betav.com/blog/billva
> www.betav.com
> Please reply only to the newsgroup so that others can benefit.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> __________________________________
>
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> So I guess what you're saying is, I can't just simply set the value of
>> an SqlConnection's ConnectionString to the value of an
>> Adodb.Connection's ConnectionString because they are built differently.
>> The fact that an ArgumentException got thrown didn't really convey what
>> the problem was.
>>
>> Thanks for the response though.
>>
>> I guess I will just use the old ADO connection for this project, until
>> i write a new login prompt in C# using the SqlConnection.
>>
>
>

It's also thick enough to be used as body armor.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

"W.G. Ryan - MVP" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I don't know where I would have been without Bill's book - it's a lifesaver
>in more ways than one.
> "William (Bill) Vaughn" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Ah, there are more differences than similarities between ADO classic
>> (COM-based) and ADO.NET. I suggest that you assume that they are
>> different from the beginning--any similarities you find along the way
>> will be a nice surprise.
>> I discuss the (copious) differences between ADO classic and ADO.NET in my
>> book (ADO.NET Examples and Best Practices).
>>
>> --
>> ____________________________________
>> William (Bill) Vaughn
>> Author, Mentor, Consultant
>> Microsoft MVP
>> INETA Speaker
>> www.betav.com/blog/billva
>> www.betav.com
>> Please reply only to the newsgroup so that others can benefit.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> __________________________________
>>
>> <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> So I guess what you're saying is, I can't just simply set the value of
>>> an SqlConnection's ConnectionString to the value of an
>>> Adodb.Connection's ConnectionString because they are built differently.
>>> The fact that an ArgumentException got thrown didn't really convey what
>>> the problem was.
>>>
>>> Thanks for the response though.
>>>
>>> I guess I will just use the old ADO connection for this project, until
>>> i write a new login prompt in C# using the SqlConnection.
>>>
>>
>>
>
>