I'm upgrading an old VB6 application to VB.NET that uses DAO to connect to an Access database. I know that this is a hopelessly outdated technology, but considering the amount of work changing to ADO, I've decided to stay with DAO, despite the frustration trying to find documentation.
My problem is that I'd like to have a DataGridView reflect a table from the database. Of course I could make my own routine manually setting the columns and fill the DataGridView, but if it is a way, I'd like to use the DataSource property or some other built-in function. I found a forum post that looked promising, but unfortunately I couldn't find the attachment that was referred to.
Also, if there are other controls better suited for this than the DataGridView, please let me know.
Thanks
DAO documentation isn't hard to find. Install VB6 and the Microsoft Developer Network (a disk was bundled with VB6). Go into the VB6 IDE, view your code, put the cursor on a DAO keyword, press F1. Presto - helpful documentation! If you prefer an online reference, the DAO documentation from Access 2007 should meet your needs very well.
So you want to bind a DataGridViewTable to a DAO table? Nice idea, but it's a big ask. Did the VB6 app use data-binding?
If it did, you're going to have a hard time migrating that to VB.Net. Consider shifting to ADO.Net in the VB.Net replacement.
If it didn't, you might be able to use DAO from VB.Net via COM and you might find that the DAO-related VB6 can be ported to DAO-related VB.Net without much effort. I don't know.
One option would be to use a method found in Code Complete. Put a nice, clean layer between the VB.NET user interface and the legacy data access code (your DAO code). The layer would take the data fetched via DAO and transfer it into a DataTable object. Then, you send the DataTable to the UI and use it as the .DataSource property of the DataGridView.
Honestly, however, since this involves writing code for each DAO function that returns data for you to display, I would just refactor your data access routines into ADO.NET. Since DAO is so, so, so old, in my opinion it would be irresponsible to be creating a "new" application and using such outdated technology, even though it technically can "work".
Related
I have recently decided to re-develop an access VBA application in VB .net with DevExpress.
I have managed to figure out databinding with the raw tables. However, I am struggling with the queries.
I have tried the query builder, but I dont have the option to save them and bind object to it. I assume it works this way? As it did in access? Or is the query builder there simply to help you format the SQL text?
I am trying to bind a DataGrid to a simply join query without any luck.
Can you someone point me in the right direction?
Thanks.
There are two main approaches that I can think of. One is to use datatables, and the other is to use domain objects.
Datatables are quick to write, can easily handle most of the heavy lifting for you (including CRUD operations) and are pretty scalable, as changes to the underlying object can be handled relatively easily.
DataTable dt = new DataTable();
Domain Objects (aka POCOs) take a lot of up-front work but typically in the log run make for a more bulletproof and robust solution. Plus, there are frameworks and even Micro ORMs that will do much of the heavy lifting for you, if you choose to use them.
List<DomainObject> do = new List<DomainObject>();
These work with tables, views or queries. You mention you have this figured out for a table, so I'm guessing you have already sort-of gotten this far.
So, first step -- figure out which direction you want to go. (pick domain objects)
Second step -- I recommend using a binding source (System.Windows.Forms.BindingSource). Make your data table / collection the DataSource for the binding source.
Third step, make the binding source the data source for your grid. If you are using a Domain Object, you'll see the columns populate automatically.
From there, once the datatable or collection is populated, you can assign it as the data source for the binding source, and .NET and Dev Express will take care of the rest for you.
bindingSource1.DataSource = dt;
or
bindingSource1.DataSource = do;
Now if you're talking CRUD operations -- that's a horse of a different color. You still use these as building blocks, but this is in no way a comprehensive answer for that.
By the way, the code above is C#, so you need minor tweaks to get this to be VB. I don't speak VB, otherwise I would have just done it like that to begin with.
Another wall in my project. I always thought that connecting to a database using VB.net is also the same on how I did it on VB6. but its totally different in my opinion.
in VB6
we just need to right click>properties>find your file. viola connection established.
then just the fields to your textboxes.
whilst in VB.Net
I tried to add ADODC the property window in VB6, doesn't appear in here since property is the property window in the right side.
one thing, can I use something like this in VB.Net? because its really far simpler than the ones that I see now about OLEDB or MySQL connection string. Its really hard.
If there is no solution to this, maybe you know a site where connecting a DB in my app seems to be easy to understand. thank you.
EDIT I need MS Access for my database..
Check out http://www.vbforums.com/showthread.php?466658.
It's a pretty decent walk through of ADO.NET..
Is using strongly typed dataset is good.
Currently I am working on a project developed using VB.Net in Visual Studio 2010.
Previously they were using Sql queries directly into SqlCommand of System.Data.SqlClient, but then after i shifted everything to Strongly Typed DataSet and started using TableAdapters every where..
Now i just wanna ask that is this way is good for a project...
Or Should i shift back to old ones using Just SqlCommands
Or Is there any way to make Sql DataBase in a good way because its an ERP and most of the code is for Data Access..
We use strongly typed datasets all the time now.
After shifting to this behaviour it felt really bad to have SQL-querys in code instead of having it done by the table adapter. But there is a bit overhead with datasets so I guess booth ways are good for different solutions.
Its really nice to have intellisence on all fieldnames and if you change a tableadapter so it returns something different you get design-time errors everywhere where you need to change the code to reflect the change, instead of finding out runtime when the customer is running the program.
There are so many win win-things with strongly typed datasets so I'll never go back.
Table adapters .... make a lot of mess with bigger databases, also updating the table structure also causes confusion.
I would recommend to use some auto code generators for the CRUD Operations.
To me your old pattern looks better than switching altogether to table adapters and strongly typed datasets.
If you ever want to move your data across the wire to other platforms (silverlight, web services, wcf services, etc), then using any kind of dataset will box you into a corner.
The way that we have resolved this is to have classes whose list of properties match the database exactly. To move the data in and out of the database, we use reflection to either match stored procedure parameters or generate dynamic SQL statements, depending on the circumstance and platform.
When a database table is changed, the developer making the change is also responsible for updating the class structure and vice-versa.
In order to reduce the amount of hand-coding required, we use the code generation capabilities of CodeSmith to generate classes from the database and create the basic implementations of our standard add/update stored procedures that require field enumeration.
As an added benefit, this approach removes the tight link between the database and business object structure. We are able to use our same data access code and business object classes against SQL Server, Oracle, Sqlite, and SqlServerCE databases. This code is used to create applications in Windows, PocketPC, Web, iPad, and Android apps; all of the mobile apps use local databases specific to the platform, but using the common data access code.
It is a bit more work to setup initially, but it will pay significant dividends in the long run.
When creating a new database in Access 2007, should ADO (ActiveX Data Objects) or DAO (Data Access Objects) be used?
Edit: Part of this database will be importing data from Excel 2007 spreadsheets.
[For the record, the official name for what once was 'Jet' is now the 'Access database engine'.]
For ACE (the Access2007 engine .accdb format) features it has to be ACEDAO.
For Jet 4.0 features it has to be ADO classic.
For Jet 3.51 features and earlier, pick either ADO or DAO. There are advantages and disadvantages to both. The vast majority of Access database engine functionality is common to both; the mutually exclusive functionality is arguable fringe. A lifestyle choice, perhaps, but no big deal. The smart coder uses the best of both :)
I've used both quite a bit and ADO is my personal preference. It is more modern than DAO, so architecturally it is an improvement: flatter object model, none of the tear down problems of DAO, etc. More properties and methods and introduces events (DAO has none) e.g. for asynchronous connection and fetching of records. ADO recordsets can be disconnected, hierarchical and fabricated, DAO recordsets cannot. Basically, they took the good things about DAO and made them better.
DAO is not without its strong points. For one, you will find more DAO code examples than ADO for Access/Jet.
P.S. for some reason, folk who like DAO really dislike ADO. Ignore the propaganda. ADO isn't deprecated. The ACE has an OLE DB provider and is currently the only way of using ACE in 64 bit. ADO.NET hasn't replaced ADO classic any more than VB.NET has replaced VBA6 in Access projects.
EDIT: just to clarify, "For Jet 4.0 features it has to be ADO classic," this is because DAO 3.6 only received a few enhancements for the features new to Jet 4.0. For example, for the DECIMAL data type you cannot specify scale/precision. Other features are missing completely from DAO. For example, can you do the following in Jet 4.0 using DAO (or ACEDAO in ACE for that matter)?
CREATE TABLE Test (
col1 CHAR(4) WITH COMPRESSION DEFAULT '0000' NOT NULL,
CHECK (NOT EXISTS (
SELECT T1.col1
FROM Test AS T1
WHERE T1.col1 <> '0000'
GROUP
BY T1.col1
HAVING COUNT(*) > 1
))
);
(hint: compressible fixed-width text column with table-level data integrity constraint.) No, you cannot.
AFAIK the only enhancements to ACEDAO was for the new ACE functionality i.e. they didn't go back and fill in the Jet 4.0 gaps in DAO. And why should they? We still have ADO to plug the gaps. Better that the team spent their time more productively, like fixing that annoying DECIMAL sort bug, for me the best thing about ACE ;-)
DAO is the is the recommended technology here. ADO has much been depreciated, and is now being replaced with ADO.net.
Not only is DAO the native and recommended data object model for using MS access, it continues to be enhanced and now has a whole bunch of new features for sharepoint. In access 2007 we now have Support for SharePoint lists. This means that new DAO object model for 2007 allows a sharepoint list to be used and viewed as a SQL server table. That means you can use SQL on sharepoint lists (in fac there not even a oleDB provider that allows you to use SharePoint lists this way, but with DAO you can now do this). There is nothing of this sort that been added to ADO. So SharePoint lists from a access (dao) point of view sees these SharePoint lists as a standard table.
Furthermore DAO in access also has support for what we call complex data types. This was done to support XML lists from sharepoint. Keep in mind for the next version of access (2010) we are going to see a whole bunch more new additional features being added to DAO (JET is now called ACE).
So it is without question that DAO is the correct and good model to use. ADO is not receiving any more enhancements, and has been superseded by ADO.NET.
So the future belongs to DAO, and it’s clear that’s where Microsoft is investing its money in terms of MS access and terms of upgrading Access to work with things sharepoint.
Access 2007 received multi-value capabilities for its field definitions, and again this was a result of enhancements for supporting sharepoint. However, these features are part of JET and these enhancements can be used without sharepoint. they are now part of DAO.
edit:
Perhaps I’m going to expand on this a little bit, and try to clarify what we have such opposing answers here, I can assure you that when using access 2007, you’re far better off to use DAO.
Where the confusion stems from, is if you look of the tools references when you choose to use the default data object model access 2007, the problem here is it’s not called DAO anymore. It is now called ACE.
When you use DAO in access 2007 You’ll note in the tool references, the reference is not set to DAO 3.6 ( that version has been depreciated, and also is now not part of MDAC download anymore). You’ll notice that the new reference when using DAO in ms-access is called:
Microsoft office 12.0 access database engine Object Library
Now the above is a bit of a mouth full, but the above is the correct for reference access 2007 when you’re going to use DAO in place of ADO.
In other words, perhaps we should call this DAO II.
In other words, this data engine continues to be enhanced, and will most assuredly see a 64 bit version of this engine for office 2010 (office 14).
So the question or confusion centers around what term were going to use when we refer to using DAO in access 2007. The confusion here is in fact that the documentation and even the tools ->reference does not call it DAO.
At the end of the day in access 2007, if you plan to use DAO then that means that you set the above reference, and do not set a reference to DAO 3.6. Regardless, it makes absolutely no sense to start using ADO now when it’s been depreciated, and the new DAO object model for access continues to be enhanced and invested in by Microsoft.
I hope this helps in clearing up the confusing here. While DAO/JET It’s being depreciated, the new version access 2007 is based on the same code base, except it continues to get enhanced. So the new data engine in access can be considered and called the new DAO object model.
I’m currently under NDA on this issue, but I can most surely tell you that for the next version of office (2010) we are going to see a whole slew of enhancements again.
So it is near unanimous among Access developers that when developing access applications and using the native data engine, the preference here is to use the DAO object model ( but keep in mind we’re not calling it that anymore, we called it ACE).
The answer to the question depends on what you're doing. If you're using Access to work with data that's in a format whose ADO interface is more versatile, then use ADO. If you're using Jet data, or using the Jet database engine to work with another database engine (via ODBC), then DAO is the right choice.
But that answer assumes you're working from Access. If you're working from some other programming environment, the answers will likely be completely different.
It depends on your needs. Neither tool is expected to disappear soon.
If you don't have experience in either ADO or DAO, you'll find DAO is much, much easier. So unless you need ADO, use DAO.
You added this critical item: "I'm trying to pull in data from an external source into an Access DB." This connectivity may require ADO.
ADO is the current recommended access method. I think DAO has been deprecated for quite a number of years.
Looks like its been since Access 2000 - according to this link,
List of obsolete data access technologies - http://msdn.microsoft.com/en-us/library/ms810810.aspx#mdac technologies road map old_topic9
Quote from the above article, which was revised Dec 2008 - "Data Access Objects (DAO): DAO provides access to JET (Access) databases. This API can be used from Microsoft Visual Basic, Microsoft Visual C++, and scripting languages. It was included with Microsoft Office 2000 and Office XP. DAO 3.6 is the final version of this technology. It will not be available on the 64-bit Windows operating system."
DAO just rocks in terms of performance compared to ADO. There's no comparison.
Apologies that this is an answer, when it should have been a comment (I do not have the rep), but I wanted to clear up an erroneous claim that DAO/ACEDAO does not support Jet 4.0 record-locking. It does, and that is the default behaviour, irrespective of what certain MS articles claim.
The problem is this may introduce huge bloat (hugely fragmented DB file) when using DAO edit/update and you cannot turn it off in DAO/ACEDAO.
If you do have this issue, you can turn it off via first opening the database via an OLEDB connection using the correct Jet OLEDB:Database Locking Mode settings, which will allow you to set the database to page-level locking. This property will then be respected by consequent connections, DAO or otherwise, so you can then use DAO for fast updates etc.
This will then allow DAO to revert to the usual 8X performance compared to executing SQL statements.
Here are a couple of links pointing to the issue:
Does ACEDAO support row level locking?
http://www.access-programmers.co.uk/forums/showthread.php?t=47040
MS KB article, including code of setting locking mode with ADO, then using DAO on that DB - http://support.microsoft.com/?id=306435
I am looking for information on the best practices or project layout for software that uses SQL embedded inside VB.NET or C#. The software will connect to a full SQL DB. The software was written in VB6 and ported to VB.NET, we want to update it to use .NET functionality but I am not sure where to start with my research. We are using Visual Studio 2005. All database manipulations are done from VB.
Update: To clarify. We are currently using SqlConnection, SqlDataAdapter, SqlDataReader to connect to the database. What I mean by embed is that the SQL stored procedures are scripted inside our VB code and then run on the db. All of our tables, stored procs, views, etc are all manipulated in the VB code. The layout of our code is quite messy. I am looking for a better architecture or pattern that we can use to organize our code.
Can you recommend any books, webpages, topics that I can google, etc to help me better understand the best way for us to do this.
I am looking for a better architecture or pattern that we can use to organize our code
...
topics that I can google
Take a look at DAL (Data Access Layer) for database transactions
Here is a link to a StackOverflow question posted by someone who is facing a similar situation
Creating a Class Library in VB.NET
When you google "How to create DAL", you will see list of how to create a DAL as well as what DAL is.
And here is a nice article that shows how DAL fits into an N-Tier achitecture
What is n-Tier Architecture?
Webopedia: N-Tier Application Architecture - Shows a nice graphical representation
It sounds like you're looking for a grand theoretical book that is written for one very specific case, i.e. what is the best practice for managing our current spaghetti SQL code framework, and I don't know that I've ever seen a book or document that describes that.
That being said, we converted several applications from VB6 to C# a few years back and were in the same place. Other than breaking apart certain modules so that their organization made more logical sense overall, our applications are essentially the same as they were, just rewritten in C#. I don't personally like the idea of separating SQL code from the function for which it was written (which is sort of what it sounds like you're trying to do); in general, if we have a function that needs to hit the database, we create a SqlCommand and, optionally, a SqlDataReader, set the CommandType to StoredProcedure and add the parameters, then perform the call and consume the result, doing with it whatever the function was programmed to do.
I don't know that that is the best way to do it, but it works for us.
Would it be possible to convert it to using LINQ? It's safer than converting it to using regular old embedded SQL statements.
In addition to what Sung Meister said, you should also consider moving the SQL from the VB.NET code into Stored Procedures, and then call the SPs from the VB.NET code (the Data Access Layer). It provides many advantages.