This statement: dim req() as Requirements only declares a reference to an array of type Requirements. It doesn't instantiate it. You need to initialize the reference to an instance of an array of that type before you can start assigning values to it. Will

I'm trying to add support for Oracle ODP.Net Bulk Data Binding to an existing component that looks a lot like the Data Access Application Block in Patterns & Practices' Enterprise Library. My problem is that an unknown (at compile time) number of arrays of unknown types can be passed in based on the database columns that are to be populated. When I try to cast an array element to String: dbParam.ArrayBindSize(i) = Convert.ToString(dbParam.Value(i)).Length or dbParam.ArrayBindSize(i) = CType(dbParam.Value(i), String).Length or dbParam.ArrayBindSize(i) = dbParam.Value(i).ToString()).Length to get it's length, the compiler complains: Option Strict On Disallows Late Binding. I know I'll get a lot of resistance if I suggest turning Option Strict Off. Is ther any other way to circumvent the compiler? Thanks In Advance. Will

I understand. My point was that: in addition to the exposed (public) fields/properties, there are NO unexposed (protected) fields/properties in the FCL's EventLog class that would be nice to get at. So, there is no point in inheriting from it. There is nothing it would provide as a base class to make it any less useless to me. Will

Thanks, I was just looking at ".NET Framework Solutions: In Search of the Lost Win32 API" over at Amazon. I haven't played with Win32 since the Windows 95 days so it's a little daunting for what should have been the simple part of the app. As far as extending the EventLog class. I don't see anything exposed as "protected" that could help me. Oh well! Will

Hi, Are there any ways to get Event Log information from a remote box other than with the EventLog class? EventLog dumps the entire collection of log entries, for the specified log, as soon as it's opened. There is no way to throttle it, Read Next, or filter on anything besides "Source". The buffer size appears to be set at 40,000 and I don't see any way to change that (not that I'd want to). Everything was going great until I tried to get a a rather large log. And of course, the solution has to be entirely from the client side and I have no control over the size of the remote server logs. Any suggestions would be appreciated. Will

Hi, Are there any ways to get Event Log information from a remote box other than with the EventLog class? EventLog dumps the entire collection of entries, for the specified log, as soon as it's opened. There is no way to throttle it, Read Next, or filter on anything besides "Source". The buffer size appears to be set at 40,000 and I don't see any way to change that (not that I'd want to). Everything was going great until I tried to get a a rather large log. And of course, the solution has to be entirely from the client side and I have no control over the size of the remote server logs. Any suggestions would be appreciated. Will

M'Kay, I see your point. I always assumed that there was a Connection object that was embedded within the Database object. That's NOT the case. If you RTFC then you'll see that each invocation of one of the wrappers "new"s its own connection (at least for SQL Server). Personally, I was happier in my deluded ignorance. I guess that means that the only way to economize is to exploit connection pooling. The various ADO.Net books seem to do a good job of covering that subject in detail. Of course, there's nothing stopping you from altering or building upon the Library except having to maintain your enhancements in future versions. In a sort of poor man's DAAB I worked on at one client site, I changed a "DatabaseHelper" class (which did have an embedded Connection object) so that it left the connection in the state it found it. If an explicit Open was performed, it stayed open until an explicit Close was performed. This runs the risk of Connection leaks if you aren't careful. Perhaps that's why the authors of the Library chose the approach that they did? Will

First, you'd probably have better luck with this question in Web Development. . I haven't done any Web Services so I don't know the environment. However in general, if you know you're going to need the connection for five calls to the database, it's a lot cheaper if you don't build and destroy the database objects and connect and disconnect five times (although I don't have a good feel for what connection pooling buys). On the other hand, if you have any sort of volume then you don't want to tie up the database resources a moment longer than necessary. So, if a Session lasts until it times out for a Web Service(?), I wouldn't allocate the connection at the Session level. Will

First, you can use the Application State or the Caching Application Block to avoid going back to the Web.config file repeatedly. Depends somewhat on whether you're doing WinForms or ASP.Net. Since you're talking about Web.config, it's obviously the latter. If you have a long chain of user controls as I do, you sure don't want every one of them creating and destroying their own database objects. I think Microsofts intention was pretty obvious when they modeled the database objects on the toolbar as something that you'd drag onto your page. Connections aren't cheap and your database server probably has a limit on the number of concurrent connections permitted so you don't want any more open at one time then necessary. Also, you stand a really good chance of deadlocking against yourself. Will

I've been putting together a simple routine to parse a streamreader, using a StringBuilder object as a buffer. Dim streamBuffer(bufferSize) As Char Dim strBldr As New StringBuilder((bufferSize * 2) + 2) Dim reader As StreamReader Do If strBldr.Length < bufferSize Then Array.Clear(streamBuffer, 0, streamBuffer.Length) streamReadLength = reader.Read(streamBuffer, 0, bufferSize) **strBldr.Append(streamBuffer)** End If . . . What seems really weird is that only some passes through the loop the StringBuilder object's Length is incremented by the size of the streamBuffer's contents but the contents are not Appended to the StringBuilder. So, while the strBldr.Length will equal say 4096, the StrBldr.ToString().Length will equal 310 and StrBldr.ToString() will produce a string that is 310 characters in length. Meanwhile, the streamBuffer field will have an array of characters in it. I've searched unsuccessfully for any reports of bugs. Anyone got any ideas? Will