|
MDAC stands for Microsoft Data Access Components and is the underlying API used by the ODBC or OLEDB data access layers. This means that any of the database access you perform in .NET is going to ultimately go through MDAC.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Thanks
I am developing a windows forms application which needs to store data locally on the client's PC.
I do not want to force the user to go through the download or installation of MDAC because I believe that it is of some 20MB in size. The setup of my application is only going to be about 1MB. How do I avoid this? Can I use some small sized embedded database? If yes, which one?
Thanks again.
|
|
|
|
|
The .NET Framework should already include the correct version of MDAC needed. For what you want to do you could use either Access or SQL Server Compact Edition (SQLCE would be my choice), but you would still need a version of MDAC.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: This means that any of the database access you perform in .NET is going to ultimately go through MDAC
Sorry to correct you here Scott, but if you go with a native providers such as the Sql Server providers then you end up going through the native driver.
|
|
|
|
|
Pete,
I thought you were correct on this but wanted to verify it, however what I found indicates my original statement is correct. From this link: Troubleshooting Data Access in Visual Studio .NET[^]
Getting the 'The .NET Data SQL Provider (System.Data.SqlClient) requires Microsoft Data Access Components (MDAC) version 2.6 or later' Error
The Microsoft Windows Software Development Kit (SDK) and the .NET Framework redistributable package do not include the MDAC installation. All .NET Framework applications that use data-access functionality require MDAC 2.6 or later (MDAC 2.8 SP1 is recommended). The latest version of MDAC is available as a download from the Microsoft Web site (http://www.microsoft.com).
Because Visual Studio installs MDAC by default, this error is most likely to occur when deploying to a computer that does not have Visual Studio installed.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: MDAC stands for Microsoft Data Access Components
Right.
Scott Dorman wrote: and is the underlying API used by the ODBC or OLEDB data access layers.
Wrong. MDAC is simply a name used for the container for various ODBC drivers and OLE DB providers. That's what the 'components' referred to are.
When you use ODBC, you're talking to the ODBC Manager. That then talks to the actual driver. In contrast when you use OLE DB your program talks directly to the Provider, but that can make use of various library facilities installed by MDAC.
Pete's correct that the SQL Server ADO.NET Provider is largely implemented in managed code - it implements the TDS protocol in managed code - but it uses the Network Library DLLs from MDAC, which is why MDAC is required. .NET Framework does not automatically install it.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
Thanks for the clarifications.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
am working on a project with the following codes:
Private Sub prono_TextChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles prono.TextChanged
obj = objordder.getIDfrmno(CStr(prono.Text))
cmdPid.Text = Val(obj)
End Sub
where objordder.getIDfrmno is the dll and cmdPid.Text is the destinesion text box
the definetion for objordder.getIDfrmno is as follows:
public object getIDfrmno(int productno)
{
SqlConnection con = new SqlConnection(constr);
string sql = "select ProductID from tblProduct where productno=" + productno + "";
SqlCommand cmd = new SqlCommand(sql, con);
con.Open();
object obj = cmd.ExecuteScalar();
con.Close();
return (obj);
}
constr is the conecction string
but not being able to get the desiered result can anyone hrlp
|
|
|
|
|
Arunava35 wrote: constr is the conecction string
What is the exact connection string you are using?
Arunava35 wrote: but not being able to get the desiered result can anyone hrlp
In what way? Is it giving you an error message? If so, what is the error message. Or is it giving you a blank screen?
Pete Soheil
DigiOz Multimedia
http://www.digioz.com
|
|
|
|
|
it is not giving an error but the result which is being shown is not correct.
|
|
|
|
|
That can only mean that your query is wrong, and/or you didn't take a foreign key relation or something along those lines into consideration.
Pete Soheil
DigiOz Multimedia
http://www.digioz.com
|
|
|
|
|
I am enumerating through a collection where the index is a string. I would like to get my hands on that string.
I am working with regular expression named groups, but the issue is the same for any collection indexed with strings.
An example:
Regex regEx = new Regex(@"^(?<name>\w+):(?<value>\w+)");<br />
Match match = regEx.Match("abc:123");<br />
GroupCollection groups = match.Groups;<br />
<br />
Console.WriteLine(groups["name"]);<br />
Console.WriteLine(groups["value"]);
(Note that the sad face emoticon in the first line should be a colon followed by a left parenthesis. I could not turn this off.)
The above writes the following to the Console:
abc
123
I would like to also write the index so the output looks like:
name = abc
value = 123
Ideally, I would like to use a foreach to print all indexes and values in the collection. This would look something like:
foreach (Group group in match.Groups)<br />
{<br />
Console.WriteLine(??? + " = " + group.Value);<br />
}
I cannot figure out what "???" should be.
Thanks.
|
|
|
|
|
I looked into this and no real solution. Have you found a way to do this?
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
No, I have not found a solution.
I suspect it is buried in the container classes or iterators some place, but I haven't had time to look.
It wasn't a high-priority issue for me, so I am currently doing without.
|
|
|
|
|
kalkwarf wrote: I suspect it is buried in the container classes or iterators some place
I would think so. For fun I am going to dig around at this and let you know if I run across anything 
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
So for the last 11 years or so I've been working to push as much of the query work in the database. So you build an objet that calls a stored proc the gives you the data that you are looking for. So now linq comes out which seems to fly in the face of that. I'm watching some of the videos on msdn and she is doing a bunch of stuff that should really be done in the database.
Am I wrong? I see some uses for link. I like the DAL but I think when you get to using join's in link you have gone too far.
|
|
|
|
|
So you see what happens when you watch too many MS videos. You start all your sentances with "So".
|
|
|
|
|
lol 
|
|
|
|
|
Personally I'm with you, I've always put as much of the data querying and data processing on to the DB as possible (where appropriate of course) because the DB is designed for such thing and is very efficient at handling large data sets.
Linq works on the current trend (.Net included) of making performance trade offs in return for ease of use in the form of productivity and maintainability.
I haven't had a chance to get to grips with Linq yet and really use it in anger so it'll be interesting to find out if it's suitable to use instead of stored procs.
One thing to remember is that Linq is about more than just databases, it allows you to do this querying with XML and even objects/collections which Stored Procs arn't so good at handling 
|
|
|
|
|
So you make it sound like Linq and Stored Procedures are mutually exclusive. I have no experience with Linq beyond reading a few articles but I would find that surprising based on my initial grasp of it.
|
|
|
|
|
Well you could use Linq on a result set returned by a stored procedure, or you could use both in their appropriate places. They arn't mutually exclusive but the OP was saying that the tutorials he's seen have been demonstrating Linq with Sql Server in situations where some people have traditionally used Stored Procs.
I was agreeing that personally I use Stored Procs in those situations but I was also trying to point out the different advantages of Linq and that it's not just limited to Sql Server.
EDIT: PS congrats on your second year as an MVP
|
|
|
|
|
Linq can be used for lots of things beyond just DB stuff. Like as a replacement for XQuery in xml docs and for searching collections.
My point is that if your just searching data from a database, linq probably isn't the best way to do it.
So I think there is a place for linq, but it's not the end all be all.
|
|
|
|
|
Tad McClellan wrote: I'm watching some of the videos on msdn and she is doing a bunch of stuff that should really be done in the database.
Microsoft, I think, try to cater for everyone. So, if you have a small project then LINQ to SQL could be useful. For an enterprise application I wouldn't rely on it.
However, you can use LINQ with stored procedures, so you can continue to keep the querying stuff in the database (where it should be) and use some of the other features of linq to do smaller tasks in the .NET application.
I am very much in the camp that the application should access the database through stored procedures only.
|
|
|
|
|
I tell you where Linq is more interesting - it's the point where you use it to perform joins on collection objects. That's when the fun begins. I agree though that Linq to Sql can lead you to do too much outside of the database and you have to be really careful that you don't pass the data context away from the DAL.
|
|
|
|
|
Pete O'Hanlon wrote: and you have to be really careful that you don't pass the data context away from the DAL.
Why ?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
