|
|||
|
Data AccessThis section contains articles covering ADO.NET, SQL Server, MSDE, Access and other data access methods and technologies.
Creating Packages with PL/SQL - 1/11/2004 Although I don't get to do as much PL/SQL programming as I'd like anymore, Oracle and PL/SQL are my first loves in programming (although with a little luck, I may get to do a lot more of it soon). I was lucky enough to get to work with an Oracle 7.0 database at the beginning of my career and then moved on to an 8i database. A short time afterward, I went to work in an environment where I used SQL Server exclusively. more... Taking advantage of the DataView's Rowfilter - 1/8/2004 If you are regular at KnowDotNet and read our Data Access section, you know I'm in love DataViews. Well, after running around evangelizing all the benefits of ADO.NET for the last two years, I came across a problem that threw me for a loop. I'm one of those obsessive/compulsive types who is driven nuts by stuff like this, and I was bound and determined to solve it! more... Check Constraints in SQL Server 2000 - 12/31/2003 These days, Relational Database Management Systems are very powerful. They do so much for you that really knowing a database like Sql Server or Oracle is quite an accomplishment. Anyway, as a programmer, the more you know the better off you are. more... ADO.NET- Supply Default Values for your Parameters - 12/31/2003 Few people are as die hard about using Stored Procedures as I am. I love everything about them, period. However, one common mistake that people make when moving to ADO.NET is forgetting to supply a value for a given parameter. Hence, when the command is executed, an exception is thrown indicating that a parameter value is missing. Remember that when you are using T-SQL in Query Analyzer for instance, you can call your procs passing parameters by position or name. You can effectively do the same in ADO.NET by not specifying a parameter name, but that's sloppy and error prone. more... IDataReader and the CommandBehavior Enumeration - 12/31/2003 If you've done much heavy lifting (or any lifting at all) in ADO.NET, you've no doubt used a DataReader. If you haven't, it's probably time that you should. Why? It's very easy to use, has a tiny footprint and in most cases, the Fastest way to retrieve data. more... Getting Intimate with your Connection - 12/30/2003 By and large, all you need to know about a IDBConnection object is that you need to Open it before you make a request and you should Close it when you are done with it. more... ADO.NET Gotcha - Remember System.Data - 12/29/2003 Recently, I was coding something using ADO.NET and my IDE appeared to be acting really wierd. All of a sudden my intellisense stopped working on a few items like ConnectionState and SqlDbType. more... Getting Schema Information from your Database - 12/27/2003 There may be times when you'll want to interrogate your database and find information about it's schema like table names, table definitions etc. ADO.NET gives us two very cool ways to accomplish this. Most of the time, when you call one of SqlClient's methods or properties, you can do the same with OleDb, Odbc etc. Most of the time, not always. In this instance however, the approach is fundamentally different. If you are using SqlClient, you simply query Sql Server's Information_Schema and restrict the results so that Table_Type = BASE TABLE. On the other hand, with OleDb (Access comes to mind on this) you open a connection, and then call its OleDbConnection.GetOleDbSchematable method. more... Change Databases Without Closing Connection - 12/27/2003 Traditionally, when I've had to switch between databases, I would usually create a new Connection object and change its ConnectionString property to point to the new database. Something about this approach made me uncomfortable and as it turns out, for good reason. Once again, it turns out that if something seems ackward, it's probably because you are doing it incorrectly. more... ADO.NET Gotcha - Why is my Query Blowing Up - 12/26/2003 One pretty common problem I see in various newsgroups is the following: Someone will post a question to the effect of "I have a query that blows up whenever I run it through ADO.NET. However, I can take the same query and run it in Access/Sql Server Query Analyzer and it runs just fine. Is this some sort of bug?" more... |
|
 |
|
|