liainaNennyb
New Member
i am having a ton of trouble using this namespace. i've installed MDAC 2.7 again and then installed ODBC.NET. The dll is in c
rogram filesmicrosoft.netodbc.net but when i try to say <%@ Import Namespace="Microsoft.Data.Odbc" %><BR>I get "The type or namespace name 'Data' does not exist in the class or namespace 'Microsoft' (are you missing an assembly reference?)"<BR><BR>Anybody got a clue as to where i am going wrong?If your application is in C:inetpubwwwroot, for instance, copy the dll to C:inetpubwwwrootin.<BR><BR>That should get it working.thanks that helped out a ton, although i think it's pretty goofy that ODBC isn't in the base framework.<BR><BR>i was having trouble with some queries in OLEDB with mySQL, but ODBC seems to be fine. I am wondering if anyone has an real information on whether ODBC or OLEDB is faster...Any speed differentials aren't great enough to matter, if they're even mesurable.<BR><BR>And yes, the only way I've been able to get mySQL to works is through ODBC as well. As far as I know, it doesn't offer OLEDB support at all. Did you get it to work?<BR><BR>Really...The only method that *does* make a considerable difference, speed-wise, is to ditch ODBC and OLEDB both, (assumimg you are using SQL Sever, which, of course, in your case you aren't) and connect via the SQL Server Managed Provider. Very, very fast.<BR><BR>This client is non-profit so mySQL is the way to go for them. <BR><BR>A company wrote an OLEDB driver for mySQL (called myOLEDB interestingly enough). It worked great, but then for some reason it would fail on any call thru .NET with a "WHERE field = value". You can do "WHERE field IN (data,data)" but whenever i did anythign with an "=" sign, it flipped out. <BR><BR>The link if you're interested is http://old.sw.com.sg/products/myoledb/ It says version 1.0, but it's really 3.0 or so.<BR><BR>ODBC is working though.Huh...Yeah, thanks for the link....I am interested. I'll check it out.<BR><BR>Glad you got it working with ODBC.
rogram filesmicrosoft.netodbc.net but when i try to say <%@ Import Namespace="Microsoft.Data.Odbc" %><BR>I get "The type or namespace name 'Data' does not exist in the class or namespace 'Microsoft' (are you missing an assembly reference?)"<BR><BR>Anybody got a clue as to where i am going wrong?If your application is in C:inetpubwwwroot, for instance, copy the dll to C:inetpubwwwrootin.<BR><BR>That should get it working.thanks that helped out a ton, although i think it's pretty goofy that ODBC isn't in the base framework.<BR><BR>i was having trouble with some queries in OLEDB with mySQL, but ODBC seems to be fine. I am wondering if anyone has an real information on whether ODBC or OLEDB is faster...Any speed differentials aren't great enough to matter, if they're even mesurable.<BR><BR>And yes, the only way I've been able to get mySQL to works is through ODBC as well. As far as I know, it doesn't offer OLEDB support at all. Did you get it to work?<BR><BR>Really...The only method that *does* make a considerable difference, speed-wise, is to ditch ODBC and OLEDB both, (assumimg you are using SQL Sever, which, of course, in your case you aren't) and connect via the SQL Server Managed Provider. Very, very fast.<BR><BR>This client is non-profit so mySQL is the way to go for them. <BR><BR>A company wrote an OLEDB driver for mySQL (called myOLEDB interestingly enough). It worked great, but then for some reason it would fail on any call thru .NET with a "WHERE field = value". You can do "WHERE field IN (data,data)" but whenever i did anythign with an "=" sign, it flipped out. <BR><BR>The link if you're interested is http://old.sw.com.sg/products/myoledb/ It says version 1.0, but it's really 3.0 or so.<BR><BR>ODBC is working though.Huh...Yeah, thanks for the link....I am interested. I'll check it out.<BR><BR>Glad you got it working with ODBC.