If I am hearing you right, you are recommending I sacrifice a virgin next full moon to absolve my transgressions. ?

The problem is that the schema doesn't mirror the objects. What I currently have working - without using an OO to Relational mapping tool - is a somewhat hyrbid OO/procedural service approach. That needs an example to explain for sure. What I mean is that I have objects which are instantiated using a static Load method, and any consistuent objects or collections of objects are loaded on demand via their getter property. The object can then be used as an object, rather than having a class with lots of static methods for performing operations on instances of that class directly in the database. Any objects that are expensive to instantiate, or are used fequently, are cached. The hybridness of the approach is that there are still certain methods which better suit the procedural service pattern, where a method such as "List me all the Customer objects with money still owing and living in canada, in an ADO Dataset, sorted by last name, without populating their Addresses collection" can be implemented as a static method of the class. These are handy for those presentation layer requirements - there is certainly no need to go creating "fat" objects to pass back to the presentation layer. My problem with hybrid approaches like these, though, are that they leave a bad taste in the mouth. Even after 3 showers and a full body exploiation I still feel a little dirty - and not in an Aguilera kind of way.

I think you mentioned some of the most important aspects that are often missing from the OR solutions that I have seen in the past, or that become issues if you let your team rely to heavily on them. Matt Gullett wrote: Providing for in-memory/multi-server caching is often automatic Having just finished off a n-wide scalable application - i.e. designed to live on as many application servers as you can afford without concurrency issues etc. - it become aparent early in the project that we would need to cache some of the heavily used objects in memory. Why? Because they were heavy in terms of database lookups; each object in the cache (~100 of them) consisted of 2 arrays of maybe a dozen other objects, and each of those contained an array of maybe another 30-40 objects. As you can imagine, that would require a shit load of database hits to instantiate each of those objects on demand without caching. Caching leads to version compatability problems, i.e. how do you refresh the caches of the the n-application servers in your farm, and now we are talking about a serious amount of overhead (resource and programming), just so that we can write our server app in an OO paradigm. Then there are other problems that enter the fray, like dealing with NULLs, casting types that might be NULL, matching primary keys to refrences, and the worst of it is that someone thoughtlessly uses an object to check one property that cost 10 database hits to retrieve, instead of writing a specialized stored proc to get in one hit. I think yo uare right though, I am just going to have to put aside a few weekends to research as many of them as possible until I find utopia.

Russell Morris wrote: Part of the reason you keep data in a relational DB is so that you can use it outside of the program that generated it. Tieing it to your OO model essentially means only the program (and version of that program) that created it can ever hope to make sense of it. Not so. Well maybe sometimes. The applications I tend to be involved in are purpose built server based systems with web client interfaces. Obviously there are certain data sharing requirements with other systems, but those are almost without fail expressed through the application layer, via web services or what-have-you. Most applications have data persistance requirements (except perhaps minesweeper), and when you are talking about highly scalable, highly transaction, blah blah server apps you need a data storage/access solution that is fast. That is where the relational DB comes into play. Now I know there are OO databases out there, but I really haven't that much exposure to them, but perhaps that is the way to get around the OO <-> relational problem. Russell Morris wrote: I think these two goals are fundamentally at odds with each other in most designs, which is why there's always a heated white-board discussion about the best way to map from one to the other. I disagree; the problem is that relational databases were not designed to solve the problem of persisting OO data, and hense whenever we try to use a RDB for that purpose, well there just aren't any clear and common guidelines. I think it is fair to say that if there was a way of solving the mapping problem that was more right than all the others than it would be a defacto standard by now. Thanks for your view though, it has got me thinking...

I heard it was 72% ... either way, if you make it not end with a zero, it is so much more valid.

Some time ago I investigated various technologies that promised to end the drudgery of mapping OO classes into relational database tables - none of them really came through on those promises. Currently I am half way through a 6 month project which is getting bogged down now the same old OO <-> relational table drudgery. I guess the idealist in me regrets that I can not rid my architecture of this last iota of non-OO code. Utopia in this regard would be never having the same 3 hour debate over the white board about the best way to instantiate, alter, save, cache, refresh, destroy, edit, create, ... our objects and how that should be represented at the relational level. I hate that debate ... I am sure I have participated in debates of that nature which have cumulatively consumed enough developer time to have fashioned a "once and for all" solution to this debate. Has anyone seen an OO to relational mapping tool or technology that worked so well it is now indespensible?

I am making a super duper custom web control with fancy client-side script. In keeping with the ASP.Net model I have decided to put my client-side script into a js file and store it with the ASP.Net ones in \aspnet_client\system_web\[version]\... I could write the HTML to include this file as part of the render process, but then I will have multiple references to the same file. Is there some way I can register with ASP.Net that I have a client-side script file to be linked like it does for it's own client-side script files? Gracias JBoy

This is a fairly old thread, but I just stumbled across it looking for an answer to a distributed transaction question I have. Anyway, does your export procedure need to be transactional? i.e. Do you want to ONLY delete the source records once they are in the remote system? And do you want the destination records to ONLY be valid once they are deleted from the source? I have architected many systems like this where the data needs to be in one place OR the the other but not both, and not get lost, like in this example. while (there are more records to export) { begin transaction; try { export record to remote system; delete record from local system; commit; } catch () { rollback; } } These systems are hard to accomplish, sometimes you are better off assuming that the 2 systems are only going to communicate asychronously and then revisit the problem you are trying to solve. If that doesn't help you one iota I won't be too suprised. JBoy

I have been investigating various test suites lately, but I am wondering what CPians use. I am especially interested in suites that target .Net and are good at testing web applications as well windows applications.

Intro: I have a simple VB application that lives in the sys tray. It basically allows me to right click and select from a list of projects I am currently working on so that I accurately keep track of what time I spend on the job and what I spend reading CodeProject. ;) Problem: Whne explorer.exe is reloaded (i.e. because IE/windows explorer hung and needed to be killed) The icon for my application does not get reloaded into the systray. How can I solve this? TIA

' This line declares variable, creates an instance of the object. Dim oAppSettings As BLL.AppSettings = New BLL.AppSettings() ' This line declares variable, no object created. Dim adorsAppSettings As ADODB.Recordset ' This line calls staatic method of already instantiated object. adorsAppSettings = oAppSettings.List ************************************ a) The COM object "BLL.AppSettings" is written in VB, there is no CreateInstance method for that object. b) VERSION is nothing to do with any of my code, so it must be part of the Interop method call mapping procedure. SOMEONE in the world MUST have had this same error for sure... Just a shame it's not documented anywhere. Thanks for looking into it though. JBoy

... Dim oAppSettings As BLL.AppSettings = New BLL.AppSettings() Dim adorsAppSettings As ADODB.Recordset adorsAppSettings = oAppSettings.List daMyDataAdpater.Fill(dsAppSettings, adorsAppSettings, "ADODB.RecordSet") dgSiteSettings.DataSource = dsAppSettings.Tables(1).DefaultView dgSiteSettings.DataBind() ... The exception is thrown on the 3rd line where the first method of the object is called. Like I said, the call never makes it to the underlying COM object, so it's not an exception occuring in that code. /shrug JBoy

I would really appreciate some clues as to what this error message means... System.Runtime.InteropServices.COMException: Resource with identifier 'VERSION' not found I am totaly stuck on this one. Nothing on MSDN, here, asp.net forums, ... I've looking all over! Only 2 results on google too!! JBoy

Ages ago I read that when ASP.Net arrived we'd be able to "package" up the whole application so that it could be shipped off to a hosting provider without worrying about them stealing IP. Did this eventuate? Or is it still on the wish list? Gracias,

I have been pawing all over the ADO.Net references and still can't see an obvious way to update a BLOB field. Any clues? TIA

Most of those questions were regarding traditional COM+ dlls. However this last question was really concerning pure .Net assemblies. Let me rephrase: 4) Rewriting my BLL and DAL objects in .Net, it seems that they would live in assemblies placed in the ASP.Net Application's /bin/ directory and no longer require registering with COM+. Thank god I say, but are these assemblies still going to run under the supervision of COM+ (IS there a COM+ in .Net)? And what happens to ObjectContexts under .Net? Since part of the role of Contexts was to ensure that MTS could manage security roles, resource management and the like; I am guessing that these benefits are inherant with any managed code. Clearly I need to learn more about what happened to COM+ services with the advent of .Net

I have a class in a Class Library project called "Foo". Here is the class... Namespace Foo Public Class Bar Shared Function HelloWorld() As String [...] End Class End Namespace I have compiled this and put the .dll Assembly into the \bin directory of a 2nd project. Project 2 is called HelloWorld2 and is a Windows Application which has a reference to the Foo.dll assembly added to it. Problem is the Import statement I need to use to access HelloWorld. I would have thought it would be Import Foo ... Public Class Form1 .... Private Sub Form1_Load(...) Handles MyBase.Load labal1.Text = Bar.HelloWorld() End Sub End Class End Sub But it seems I have to do Import Foo.Foo Why the extra Foo? Bah humbug!!

I have recently been re-evaluating the way our middle tier objects are designed and coded, including looking at their future under .Net I guess to a large extent some of my methods of coding middle tier objects have been inherited from other people's code without a complete understanding of why. A few questions have arisen regarding the use of ObjectContext to create objects and so forth, especially in regard to COM+, but also wondering how things will change moving to .Net 1) All middle tier object instatiating (BLL creates DAL object, or BLL creates different BLL object) uses ObjectContext.CreateInstance. As I understand it, this will ensure the created object executes within the activity, the transaction (if there is one) and the security context of the client object. Assuming my object is non transactional and I am not using security roles or such, do I still need to create objects in this manner? 2) Looking at the data access "helper" methods I see that someone has decided to ObjectContext.CreateInstance ADO objects. Is this wise? Are they threaded in such a way as to make them safe to run in an MTS activity? 3) All the documentation on ObjectContext talks about MTS, but there is no mention of it in the COM+ docs. Is there a good reason for this? What happened to ObjectContext in COM+? 4) In .Net it seems that my BLL and DAL objects would live in assemblies placed inteh ASP.Net Application's /bin/ directory and no longer require registering with COM+. Thank god I say, but are these assemblies still going to run under the supervision of COM+? And what happens to ObjectContexts under .Net? Even if I could be pointed in the direction of some useful reading material that would be swell.

This is more of a configuration question. I have a firewall between me and a DCOM component that is only letting allowing DCOM traffic (or more specifically I guess RPC traffic) through ports 135 and 40000-40001. I have followed instructions on how to achieve this from such entertaining articles such as "Using Distributed COM with Firewalls" (from MSDN) but to no avail. My component is still trying to establish a connection through any random port it likes. Although I'm well versed in details of TCP and the like I am a bit lost as to how to diagnose the problem here. A nod in the right direction would really be appreciated. Typically, most of the article I'm coming across are knee deep in most details but then skip quickly over the art of configuring the security aspects. TIA JBoy

User controls ignore and

tags, so it would not be possible to have a Header user control that defines say the following ... Northwind

JBoy :confused: