Adding a new, disconnected object, setting it as change tracking root, and setting a reference property to an existing database object

May 12, 2008 at 1:34 PM
Edited May 12, 2008 at 2:39 PM
Matt,

First, let me say that this is a great project. I've been playing with some modifications to make it easier to refresh an object tree from a data source. If you're interested, I'll shared them with you.

My question centers around creating new objects. I have a WorkSequence object that has a Type property that references a Type object. When I create a new WorkSequence, set the Type property to an existing Type object retrieve from the database, and call SetAsChangeTrackingRoot(LINQEntityState.New, True); on the WorkSequence, I get an error when I try synchronizing with a DataContext as the Type object already exists and adding a new one would violate the primary key of the table. Do you have any suggestions as to how to deal with this situation? I can see that it's caused by SetAsChangeTrackingRoot going through the entire entity tree and setting all of the child objects' LINQEntityState property to the initialState value that is passed in, in this case LINQEntityState.New.

Thanks for any input you can provide; in the mean time, I'll keep playing and see if I can find a solution. Keep up the great work!

Stephan

Edit: Matt, my apologies for this question. I discovered that it is actually an issue with the way LINQ to SQL handles InsertOnSubmit. It's documented on an MSDN forum at http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2886652&SiteID=1. I will continue my research as to how to accomplish this.
Coordinator
May 13, 2008 at 5:48 AM
Hi Stephan,

Yes, I think I see the problem here.

I haven't tried this, but this is what you might be able to do, a bit of a hack until I can come up with something:

With the object that you are adding setting to the property, Call it's SetAsChangeTrackingRoot() method before you assign it to the WorkSequence  object.  This will force it to be "original" state and it won't set it to "New" state (and cause an insert later on)...

Give it a try - it might work.

I'll see if I can work through it a little more when I have time in the next few days.

Cheers

Matt.
Coordinator
May 13, 2008 at 5:53 AM
Forgot to mention, the above hack should be done after you've set SetAsChangeTrackingRoot() on the WorkSequence object.

Cheers

Matt.
May 13, 2008 at 12:20 PM
Thanks for the quick response, Matt. I actually tried your "hack", so to speak, early yesterday as well and found that it didn't work either. After some research, it appears that in the SynchroniseWithDataContext() method, when the line targetDataContext.GetType( typeof(entity) ).InsertOnSubmit( entity ); runs, the data context thinks that the FK reference to the Type entity is new, since the DC doesn't have it in the cache.

The MSDN article I reference in my previous post does accurately describe the problem, although no one seems to have come up with a fix. Therefore, I did some investigating myself and came up with the following code change. Feel free to incorporate it if you think it'll benefit others. The changes are in the SynchroniseWithDataContext() method. All I do is traverse the foreign key references for the parent entity, if its LINQEntityState property is EntityState.New, and attach them to the appropriate DC table if the child entity does not have an EntityState.New state.

                .
                .
                else if (entity.LINQEntityState == EntityState.New)
                {
                    //SFD addition: if the entity's state is new, traverse non-new foreign keys and attach to datacontext to prevent insertion errors (duplicate primary keys)
                    if (entity.LINQEntityState == EntityState.New)
                    {
                        LINQEntityBase fkProp;
                        foreach (PropertyInfo fkPropInfo in entity._entityAssociationFKProperties.Values)
                        {
                            fkProp = fkPropInfo.GetValue( entity, null ) as LINQEntityBase;
                            if (fkProp != null && fkProp.LINQEntityState != EntityState.New)
                                targetDataContext.GetTable( fkProp.GetType( ) ).Attach( fkProp, false );
                        }
                    }
                    targetDataContext.GetTable( entity.GetType( ) ).InsertOnSubmit( entity );
                }
                .
                .

That seems to take care of the issue I was running into.

Cheers!
Stephan


Coordinator
May 14, 2008 at 11:14 AM


sdesmoulin wrote:
Thanks for the quick response, Matt. I actually tried your "hack", so to speak, early yesterday as well and found that it didn't work either. After some research, it appears that in the SynchroniseWithDataContext() method, when the line targetDataContext.GetType( typeof(entity) ).InsertOnSubmit( entity ); runs, the data context thinks that the FK reference to the Type entity is new, since the DC doesn't have it in the cache.

The MSDN article I reference in my previous post does accurately describe the problem, although no one seems to have come up with a fix. Therefore, I did some investigating myself and came up with the following code change. Feel free to incorporate it if you think it'll benefit others. The changes are in the SynchroniseWithDataContext() method. All I do is traverse the foreign key references for the parent entity, if its LINQEntityState property is EntityState.New, and attach them to the appropriate DC table if the child entity does not have an EntityState.New state.

                .
                .
                else if (entity.LINQEntityState == EntityState.New)
                {
                    //SFD addition: if the entity's state is new, traverse non-new foreign keys and attach to datacontext to prevent insertion errors (duplicate primary keys)
                    if (entity.LINQEntityState == EntityState.New)
                    {
                        LINQEntityBase fkProp;
                        foreach (PropertyInfo fkPropInfo in entity._entityAssociationFKProperties.Values)
                        {
                            fkProp = fkPropInfo.GetValue( entity, null ) as LINQEntityBase;
                            if (fkProp != null && fkProp.LINQEntityState != EntityState.New)
                                targetDataContext.GetTable( fkProp.GetType( ) ).Attach( fkProp, false );
                        }
                    }
                    targetDataContext.GetTable( entity.GetType( ) ).InsertOnSubmit( entity );
                }
                .
                .

That seems to take care of the issue I was running into.

Cheers!
Stephan

Hi Stephan,

Thanks for the code... I think i see it more clearly now with you fix.

I'll have to go through it, but initial review it seems like it would work!  Unless I'm missing something, i'll also need to do something similar for the other record status's as well - otherwise they'll also assume inserts on FK's.

It may be simpler to do the following:
1. Traverse FK values first, attaching them as modified = false as you've done above.
2. Process all other records.

This should stop MS from automatically assuming inserts on these relationships.

Let me know if I've missed the point, but I think I've got it.

Thanks very much for the heads up on the MS issue and the code, feel free to contribute more :)

Cheers

Matt.
May 14, 2008 at 1:33 PM
Edited May 14, 2008 at 1:34 PM
I thought as you did at first as well, but it seems that the problem only occurs when an entity is InsertOnSubmitted. When it's attached, as you do when it's modified, deleted, or original, FK references don't seem to have the same problem. I think the SubmitChanges method on the DataContext object only assumes a new object if the parent is inserted as new. When attached, I think it considers child objects as already existing as well. I haven't done enough testing to bear this assumption out and I haven't found any concrete information from Microsoft confirming this, so feel free to verify it. :)

While we're on the subject of DataContext quirks, I found another one when trying to delete an object with a non-nullable FK reference. The behavior is detailed in this MSDN post, http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2275447&SiteID=1, and it appears to still be plaguing things now. As of the RTM release of VS 2008, the DeleteOnNull="true" attribute is specified on all non-nullable FK associations in the dbml file; however, I still get the error message. I'm working on a fix for that as well and I'll post it as soon, and if, I can find it. Curiously, for this one, your code does do an Attach followed by a DeleteOnSubmit as is described in the fix. So, I'm still a bit confused. If you have any suggestions for this one as well, even though it's not your issue, I'd appreciate it.

Aren't frameworks a blast?!

Thanks!
Stephan

May 14, 2008 at 7:46 PM
I'm still working on figuring out the deletion problem, though I think I found a solution for the time being. However, since the time when I posted the code snippet for FK references when adding an object, I did discover a problem. Assuming that a WorkSequence entity has an EntitySet<> of Step entities, when I add a new Step entity to the collection and try to sychronise with the datacontext, I receive an error stating that an object cannot be attached twice. The following snippet illustrates the changes that I made from the previous snippet to get around this issue.

                            if (fkProp != null && fkProp.LINQEntityState != EntityState.New)
                            {
                                try
                                {
                                    targetDataContext.GetTable( fkProp.GetType( ) ).Attach( fkProp, false );
                                }
                                catch
                                {
                                }
                            }

I'm using the error handling method for now until I can figure out how to determine if an entity is already attached to the datacontext without causing the DC to requery the database. As for why the problem occurs, it's quite simple. The first entity to be traversed is the root entity (WorkSequence), which gets attached to its table. Then, when going through the Step objects, the routine encounters the new Step object and tries to attach the FK reference to the WorkSequence entity.

My apologies for the bug, and if you have any suggestions as to how to find out if an object is already attached to a DC, I'm all ears.

As always, feel free to comment on everything I write and use the sample code in my post. I think you're on to something with the disconnected LINQ scenario and I'm willing to help you out with perfecting it if you like.

Cheers!
Stephan
Coordinator
May 17, 2008 at 10:49 AM


sdesmoulin wrote:
I thought as you did at first as well, but it seems that the problem only occurs when an entity is InsertOnSubmitted. When it's attached, as you do when it's modified, deleted, or original, FK references don't seem to have the same problem. I think the SubmitChanges method on the DataContext object only assumes a new object if the parent is inserted as new. When attached, I think it considers child objects as already existing as well. I haven't done enough testing to bear this assumption out and I haven't found any concrete information from Microsoft confirming this, so feel free to verify it. :)

While we're on the subject of DataContext quirks, I found another one when trying to delete an object with a non-nullable FK reference. The behavior is detailed in this MSDN post, http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2275447&SiteID=1, and it appears to still be plaguing things now. As of the RTM release of VS 2008, the DeleteOnNull="true" attribute is specified on all non-nullable FK associations in the dbml file; however, I still get the error message. I'm working on a fix for that as well and I'll post it as soon, and if, I can find it. Curiously, for this one, your code does do an Attach followed by a DeleteOnSubmit as is described in the fix. So, I'm still a bit confused. If you have any suggestions for this one as well, even though it's not your issue, I'd appreciate it.

Aren't frameworks a blast?!

Thanks!
Stephan



Hi Stephan,

New & FK's --> Sounds about right, it would only do it on new's.  I'll add your code into the fold next opportunity.

Delete issues --> Sorry don't have any experience on this one, however if you shoot me a small project that demonstrates it I'll be happy to take a look, there might be something that can be done.

Cheers

Matt.
Coordinator
May 17, 2008 at 11:14 AM


sdesmoulin wrote:
I'm still working on figuring out the deletion problem, though I think I found a solution for the time being. However, since the time when I posted the code snippet for FK references when adding an object, I did discover a problem. Assuming that a WorkSequence entity has an EntitySet<> of Step entities, when I add a new Step entity to the collection and try to sychronise with the datacontext, I receive an error stating that an object cannot be attached twice. The following snippet illustrates the changes that I made from the previous snippet to get around this issue.

                            if (fkProp != null && fkProp.LINQEntityState != EntityState.New)
                            {
                                try
                                {
                                    targetDataContext.GetTable( fkProp.GetType( ) ).Attach( fkProp, false );
                                }
                                catch
                                {
                                }
                            }

I'm using the error handling method for now until I can figure out how to determine if an entity is already attached to the datacontext without causing the DC to requery the database. As for why the problem occurs, it's quite simple. The first entity to be traversed is the root entity (WorkSequence), which gets attached to its table. Then, when going through the Step objects, the routine encounters the new Step object and tries to attach the FK reference to the WorkSequence entity.

My apologies for the bug, and if you have any suggestions as to how to find out if an object is already attached to a DC, I'm all ears.

As always, feel free to comment on everything I write and use the sample code in my post. I think you're on to something with the disconnected LINQ scenario and I'm willing to help you out with perfecting it if you like.

Cheers!
Stephan


Hi Stephan,

This is very bizarre...

A couple of things to check:

- Is the object actually new as in totally new data?
- Is this object reference by another object?
- Have you disconnected the data from the data context before re-attaching to a new one?
- Make sure you are doing a "db.DeferredLoadingEnabled = false" before you use the DC you are going to syncronise with.

Stephan, keep those issues (and solutions) coming!!!! Would love your help making this thing better...

What might be useful is if you can re-produce these issues by using the dbml file in the example I ship? That way I'll be able to see these issues without having to understand what the complexitiesof what you are trying to do.   It also might help you realise what the problem is.  Email me through the code if you have the time.

Cheers

Matt.

Coordinator
May 18, 2008 at 12:40 AM

Hi Stephan,

back to the original issue, i've just modified the Example that I ship with LINQ to SQL and I can't get the same issue you are getting.

Tell me if this is similar to what you are doing:

1. Created an new Order

2. Created a new Order Detail (referencing a product retrieved from the database) and attach it to the order.

3. Add the order to an existing customer.

The only difference I think we have is that I'm attaching the order to an existing customer instead of the customer being new.  Is it possible you are not disconnecting the records (type records) before you reference them?  Also, check your relationships... in your dbml Type should point in the direction of your Worksequence, not the other way round.

One more thing, the way I do my queries is always Customer-->Order-->Order_Details... I do not actually get the reference data as part of this (i.e. products) - i load this seperately (i.e. if you go and try an get the product from the order details record, it will be null although the property productid will have value).  Perhaps you are retrieving the referenced data as well with the worksequence data?  I suggest not to do this because you will run into issues with attaching.

Also, check out the latest source code to look at what I have done... perhaps it will help.

Cheers

Matt.

May 19, 2008 at 12:20 PM


mhunter wrote:


sdesmoulin wrote:
I'm still working on figuring out the deletion problem, though I think I found a solution for the time being. However, since the time when I posted the code snippet for FK references when adding an object, I did discover a problem. Assuming that a WorkSequence entity has an EntitySet<> of Step entities, when I add a new Step entity to the collection and try to sychronise with the datacontext, I receive an error stating that an object cannot be attached twice. The following snippet illustrates the changes that I made from the previous snippet to get around this issue.

                            if (fkProp != null && fkProp.LINQEntityState != EntityState.New)
                            {
                                try
                                {
                                    targetDataContext.GetTable( fkProp.GetType( ) ).Attach( fkProp, false );
                                }
                                catch
                                {
                                }
                            }

I'm using the error handling method for now until I can figure out how to determine if an entity is already attached to the datacontext without causing the DC to requery the database. As for why the problem occurs, it's quite simple. The first entity to be traversed is the root entity (WorkSequence), which gets attached to its table. Then, when going through the Step objects, the routine encounters the new Step object and tries to attach the FK reference to the WorkSequence entity.

My apologies for the bug, and if you have any suggestions as to how to find out if an object is already attached to a DC, I'm all ears.

As always, feel free to comment on everything I write and use the sample code in my post. I think you're on to something with the disconnected LINQ scenario and I'm willing to help you out with perfecting it if you like.

Cheers!
Stephan


Hi Stephan,

This is very bizarre...

A couple of things to check:

- Is the object actually new as in totally new data?
- Is this object reference by another object?
- Have you disconnected the data from the data context before re-attaching to a new one?
- Make sure you are doing a "db.DeferredLoadingEnabled = false" before you use the DC you are going to syncronise with.

Stephan, keep those issues (and solutions) coming!!!! Would love your help making this thing better...

What might be useful is if you can re-produce these issues by using the dbml file in the example I ship? That way I'll be able to see these issues without having to understand what the complexitiesof what you are trying to do.   It also might help you realise what the problem is.  Email me through the code if you have the time.

Cheers

Matt.



Hi Matt,

I'm tackling this question first, but I'll post a small project later today, hopefully I've got time, that demonstrates all of these issues. This particular issue should be reproducible in your example solution as well. The first step is to query the database for a Customer object. Next, create a new Order object and .Add it to the Customer's Orders collection. Then, synchronise the Customer with a new DataContext. If you have the fix in for new objects (if (fkProp != null && fkProp.LINQEntityState != EntityState.New) and associated lines), you should get the error message. The way I figured it out was to step through the debugger in the SynchroniseWithDataContext method. I saw that the first entity to get processed from the ToEntityTree( ) list was the parent entity (Customer). Once the child entity (new Order) gets processed, the code tried, because of the fix I had put in, to Attach the FK reference to the Customer entity. The Customer had already been attached, thereby causing the Cannot attach an already attached object message. Hopefully this is clear enough.

By the way, do you have any objection to the sample project being in VB versus C#? I already have most of the sample, since it is a project I'm working on for my company, in VB and it would probably be easier to leave it as such, unless you'd rather have it in C#.

Thanks!
Stephan
May 19, 2008 at 12:38 PM


mhunter wrote:

Hi Stephan,

back to the original issue, i've just modified the Example that I ship with LINQ to SQL and I can't get the same issue you are getting.

Tell me if this is similar to what you are doing:

1. Created an new Order

2. Created a new Order Detail (referencing a product retrieved from the database) and attach it to the order.

3. Add the order to an existing customer.

The only difference I think we have is that I'm attaching the order to an existing customer instead of the customer being new.  Is it possible you are not disconnecting the records (type records) before you reference them?  Also, check your relationships... in your dbml Type should point in the direction of your Worksequence, not the other way round.

One more thing, the way I do my queries is always Customer-->Order-->Order_Details... I do not actually get the reference data as part of this (i.e. products) - i load this seperately (i.e. if you go and try an get the product from the order details record, it will be null although the property productid will have value).  Perhaps you are retrieving the referenced data as well with the worksequence data?  I suggest not to do this because you will run into issues with attaching.

Also, check out the latest source code to look at what I have done... perhaps it will help.

Cheers

Matt.



Hi Matt,

I'll attempt to be more clear about the original issue, as well as giving each step I took to run into the problem. I'll also have the code in the sample project I'll post later today. I'll be using my original entities as I'm more familiar with those. Just to recap, a WorkSequence has a one-to-many relationship to Step entities and an FK reference to a Type entity (Type has a one-to-many relationship to WorkSequence). The sample will have a dbml and database definition project as well, just in case.
  1. Using a brand new DC with DeferredLoadingEnabled=false, I run a dc.Types.ToList() and store the resulting generic list
  2. An item from the stored Type list is picked from a menu to create a new WorkSequence
  3. The new WorkSequence is created and the Type property (FK reference to the Type table) is set to the selected (existing in the database) Type instance from the stored list
  4. The WorkSequence is set as the change tracking root object
  5. I call (WorkSequence entity).SynchroniseWithDataContext( ) on a brand-new DC with DeferredLoadingEnabled=false
  6. Without the fix I mentioned previously for inserting new objects, the Duplicate Primary Key error occurs
Now that you mention it, I am pulling in the Type information as well when loading a WorkSequence, but I have not encountered this problem with an existing WorkSequence, only when creating a brand new one with a reference to an existing Type. However, I wonder if I only set the TypeId property on the new WorkSequence if I would get the same error. Ideally, I like to be able to work with the object tree, which may very well be why I ran into this problem in the first place. :)

Hopefully this is clearer; if not, the sample project should clear everything up.

Thanks!
Stephan
Coordinator
May 19, 2008 at 10:31 PM
Edited May 19, 2008 at 10:32 PM
Hi Stephan,

This is what I have to try and reproduce the issue - still can't, can you tell me if you are doing something different? (BTW, VB is fine if you want to post/send me source code in VB).

Cheers

Matt.

            Customer customer;
            List<Product> products;          

            using (NorthWindDataContext db = new NorthWindDataContext())
            {
                db.DeferredLoadingEnabled = false;

                products = db.Products.ToList();

                customer = (from c in db.Customers
                           where c.CustomerID == "ALFKI"
                           select c).FirstOrDefault();

                customer.SetAsChangeTrackingRoot();

                Order orderAdded = new Order()
                {
                    EmployeeID = 3,
                    OrderDate = DateTime.Now,
                    RequiredDate = DateTime.Now.AddDays(30),
                    ShippedDate = DateTime.Now.AddDays(10),
                    ShipVia = 1,
                    Freight = 10,
                    ShipName = "I have been added",
                    ShipAddress = "Obere Str. 57",
                    ShipCity = "Berlin",
                    ShipRegion = null,
                    ShipPostalCode = "12209",
                    ShipCountry = "USA"
                };

                customer.Orders.Add(orderAdded);

                Order_Detail order_DetailAdded = new Order_Detail()
                {
                    UnitPrice = 55,
                    Quantity = 10,
                    Discount = 0.15F
                };

                order_DetailAdded.Product = products.FirstOrDefault();

                orderAdded.Order_Details.Add(order_DetailAdded);

            }

            using (NorthWindDataContext db = new NorthWindDataContext())
            {
                db.DeferredLoadingEnabled = false;
                customer.SynchroniseWithDataContext(db);
                db.SubmitChanges();
            }

 

May 20, 2008 at 12:11 PM


mhunter wrote:
Hi Stephan,

This is what I have to try and reproduce the issue - still can't, can you tell me if you are doing something different? (BTW, VB is fine if you want to post/send me source code in VB).

Cheers

Matt.

            Customer customer;
            List<Product> products;          

            using (NorthWindDataContext db = new NorthWindDataContext())
            {
                db.DeferredLoadingEnabled = false;

                products = db.Products.ToList();

                customer = (from c in db.Customers
                           where c.CustomerID == "ALFKI"
                           select c).FirstOrDefault();

                customer.SetAsChangeTrackingRoot();

                Order orderAdded = new Order()
                {
                    EmployeeID = 3,
                    OrderDate = DateTime.Now,
                    RequiredDate = DateTime.Now.AddDays(30),
                    ShippedDate = DateTime.Now.AddDays(10),
                    ShipVia = 1,
                    Freight = 10,
                    ShipName = "I have been added",
                    ShipAddress = "Obere Str. 57",
                    ShipCity = "Berlin",
                    ShipRegion = null,
                    ShipPostalCode = "12209",
                    ShipCountry = "USA"
                };

                customer.Orders.Add(orderAdded);

                Order_Detail order_DetailAdded = new Order_Detail()
                {
                    UnitPrice = 55,
                    Quantity = 10,
                    Discount = 0.15F
                };

                order_DetailAdded.Product = products.FirstOrDefault();

                orderAdded.Order_Details.Add(order_DetailAdded);

            }

            using (NorthWindDataContext db = new NorthWindDataContext())
            {
                db.DeferredLoadingEnabled = false;
                customer.SynchroniseWithDataContext(db);
                db.SubmitChanges();
            }

 



Hi, Matt; what a conundrum this is. That is almost exactly what I'm doing. The only thing that may be different is are you using the code block below in SynchroniseWithDataContext( )?

                .
                .
                else if (entity.LINQEntityState == EntityState.New)
                {
                    //SFD addition: if the entity's state is new, traverse non-new foreign keys and attach to datacontext to prevent insertion errors (duplicate primary keys)
                    if (entity.LINQEntityState == EntityState.New)
                    {
                        LINQEntityBase fkProp;
                        foreach (PropertyInfo fkPropInfo in entity._entityAssociationFKProperties.Values)
                        {
                            fkProp = fkPropInfo.GetValue( entity, null ) as LINQEntityBase;
                            if (fkProp != null && fkProp.LINQEntityState != EntityState.New)
                                targetDataContext.GetTable( fkProp.GetType( ) ).Attach( fkProp, false );
                        }
                    }
                    targetDataContext.GetTable( entity.GetType( ) ).InsertOnSubmit( entity );
                }
                .
                .

If so, it won't cause an error. I never got a chance to post the code yesterday evening, but I should be able to tonight. I'll zip up the solution and post a link here to my website. I'll also make sure to include extra comments with expected and actual results.

Thanks!
Stephan

Coordinator
May 27, 2008 at 5:34 AM

Hi Stephan,

I have repeated the "already attached" problem (although it may not be 100% the same as your issue), figured out whats going on, and made a small alteration and hope this will help you with your issue.

In SyncroniseWithDataContext, change the line:

List<LINQEntityBase> entities = this.ToEntityTree().ToList();

TO

List
<LINQEntityBase> entities = this.ToEntityTree().Distinct().ToList();

 

 

This will remove the duplicates from the list when syncronising, and should stop the "already attached" error message.

I will update the source code tonight with the fix, when I have a chance.

Cheers

Matt

 

Jun 10, 2008 at 4:50 PM


mhunter wrote:

Hi Stephan,

I have repeated the "already attached" problem (although it may not be 100% the same as your issue), figured out whats going on, and made a small alteration and hope this will help you with your issue.

In SyncroniseWithDataContext, change the line:

List<LINQEntityBase> entities = this.ToEntityTree().ToList();

TO

List
<LINQEntityBase> entities = this.ToEntityTree().Distinct().ToList();

 

 

This will remove the duplicates from the list when syncronising, and should stop the "already attached" error message.

I will update the source code tonight with the fix, when I have a chance.

Cheers

Matt

 



Hi Matt,

Sorry for the response delay. I was on vacation. Can I say "duh!" in response? This little change is indeed orders of magnitude simpler than my error checking mechanism. Sometimes it helps just to not be involved with a problem to find a solution :). Thanks a lot!

As for my use case source code, I'll get it posted tonight. I ended up not having any time before the vacation for it.

Thanks,
Stephan

Coordinator
Jun 13, 2008 at 11:36 AM
Ok,

thanks Stephan.

Cheers

Matt.