Resources / Useful / Tips (1 Viewer)

Uncle Gizmo

Nifty Access Guy
Staff member
Local time
Today, 07:00
Joined
Jul 9, 2003
Messages
16,287
Before the hacking there was a thread with some useful stuff in, which I hope we can reproduce here.

I have just found this "Code Search Engine --- Koders ---" which you can use to search for code. I haven't worked out if it's any good or not yet! I can't find much stuff within it useful for Microsoft Access, (VBA) however it can search for VB stuff, Which sometimes lends itself to MS Access.

However it does have the ability to search for VB.Net code which is why I have included it here.
 

skea

Registered User.
Local time
Today, 09:00
Joined
Dec 21, 2004
Messages
342
Good Link, but alas!...most of it is in the C++ line.
I wonder how one can tell that this is VB.net code without passing from one thread to another!
 

MadMaxx

.NET foo
Local time
Today, 02:00
Joined
Jun 27, 2003
Messages
138
Here is another.

Still in beta but should be up soon.

Krugle
 

Uncle Gizmo

Nifty Access Guy
Staff member
Local time
Today, 07:00
Joined
Jul 9, 2003
Messages
16,287
I think this article will be of interest to MS Access programmers moving up to VB.Net.

Extract:
I asked myself if there was something as simple to use (in VB.Net) as the DAO or ADO recordset. I couldn't find any. The other thing about ADO.NET is that most articles talk about using wizards that auto-build extensive code specifical to a data format. What if the database structure changes? What do I have to do? Rebuild the form completely???

Based on this, I started building this simple library that simulates a recordset, and another that performs a fake binding...but that's another story.
 

Kodo

"The Shoe"
Local time
Today, 02:00
Joined
Jan 20, 2004
Messages
707
The DataReader is the closest thing you're going to get to the recordset object.
No offense, but what you have created is missing HUGE amounts of functionality that already exists in ADO.NET.

I recommend AGAINST using things like the SqlCommandBuilder/ table adapters and any drag n'drop creation of datasources. Get into the code and really get dirty.

The reason that things like the DataSet and DataTable are so complicated are because they are disconnected sets. If you work in a datatable and need to update the source, then this is where ADO.NET comes in. You need to make sure you're updates don't conflict with others.

ADO.NET is huge and mean big. It's ALMOST like another language mainly because it brings database concepts to OOP which is something that we rarely messed with except when we were IN the database. Now we can have mini-databases in memory that represent data in the database.

As for "if the db changes... " that's the beauty of ADO.NET. If the db changes then your stored procedures can alias field names and essentially massage the underlying structural changes so that your application doesn't suffer. There's so much more to it than that and I haven't even begun to scratch the scratches on the surface. Heck, I have 2 books on ADO.NET alone much less the 5 or 6 other books I have on VB, C#, the BCL, Patterns & Practices, ASP.NET.. man, you name it. .NET requires a large investment in time and patience to get used to its' complexitites. In fact, I have become quite fond of ADO.NET and it's native XML support allowing me to build mini-rleational db's in memory (like 2 tables). It allows me to perform db like functionality in memory while never having to hit the db but once. Not to mention it's WICKED fast too!
 

WindSailor

Registered User.
Local time
Yesterday, 23:00
Joined
Oct 29, 2003
Messages
239
Data Access Application Block for .NET v2

http://www.microsoft.com/downloads/...0A-9877-4A7B-88EC-0426B48DF275&displaylang=en

Overview
Are you involved in the design and development of data access code for .NET-based applications? Have you ever felt that you write the same data access code again and again? Have you wrapped data access code in helper functions that let you call a stored procedure in one line? If so, the Microsoft® Data Access Application Block for .NET is for you.

The Data Access Application Block encapsulates performance and resource management best practices for accessing Microsoft SQL Server™ databases. It can easily be used as a building block in your own .NET-based application. If you use it, you will reduce the amount of custom code you need to create, test, and maintain.

Important Information: A newer version of this application block has been released as a part of the patterns & practices Enterprise Library.

http://www.microsoft.com/downloads/...70-406B-4F2A-B723-97BA84AE80B5&displaylang=en

The new version includes updated functionality based on customer feedback, as well as improved extensibility, ease of use, and consistency and integration with other blocks in Enterprise Library. The application block you have requested is still available for download but is now considered as an archive release.


patterns & practices: Events and Webcasts

http://msdn.microsoft.com/practices/Webcasts/
 

Kodo

"The Shoe"
Local time
Today, 02:00
Joined
Jan 20, 2004
Messages
707
The Enterprise Library (or EntLib) is a superb library indeed! I use it at work relegiously and it saves me loads of time from having to code all my own CRUD.
I highly suggest it!
 

Users who are viewing this thread

Top Bottom