Alternatives?

semaphore said:
You perhaps not swallowing an exception higher up in the call stack? So while you "think" it works, it actually doesn't? Perhaps an invalid datatype attempted at saving.
Click to expand...

Hmm.. Lemme refresh the model and reattempt?

When I save it to the type "AfricaStuff" if there was a type issue it wouldn't compile even would it?

Lemme comb through this again.
 
Necropolis said:
This is why I prefer handling DB connections myself.
Click to expand...

It has nothing to do with the way DB connections are handled. Entityframework is more than efficiently doing that. Its the person implementing the DataContext that is at fault.
 
Pho3nix said:
Hmm.. Lemme refresh the model and reattempt?

When I save it to the type "AfricaStuff" if there was a type issue it wouldn't compile even would it?

Lemme comb through this again.
Click to expand...

Move that submit on changes out the loop as well and see if it makes a difference. Creating transaction scopes for thousands of small records is stupid.
 
semaphore said:
Move that submit on changes out the loop as well and see if it makes a difference. Creating transaction scopes for thousands of small records is stupid.
Click to expand...

:D:D

so rather :
Code: 
                foreach (AfricaStuff item in africaStuff )
                {
                    dataContext.AfricaStuff.InsertOnSubmit(item);
                }
                dataContext.SubmitChanges();
 
Last edited:
Fuma said:
Huh? I thought you'd never touch EF with anything.
Click to expand...

I wouldn't but it does not mean I have not been forced to use it on previous legacy projects. Anything I do these days is without an ORM.
 
Pho3nix said:
:D:D

so rather :
Code: 
                foreach (AfricaProjectsSharePoint item in africaProjects)
                {
                    dataContext.AfricaStuff.InsertOnSubmit(item);
                }
                dataContext.SubmitChanges();
Click to expand...

Yeah, I doubt it will resolve your issue though.
 
Pho3nix said:
So rather then debugging this.. Idea's on possible alternative's that can do the same thing but aren't a WCF service?
Need to be kicked off by a SSIS package.
Click to expand...

Get that idea out of your head, you should rather fix the issue. As it could be an underlying problem.
 
What exactly is the service doing?

Couldn't you package it all up in a script task within SSIS?
 
semaphore said:
Get that idea out of your head, you should rather fix the issue. As it could be an underlying problem.
Click to expand...

I agree. Rather find the root cause. You have smoke here, so need to find the cause of the fire. After rewriting, you most likely will just hit the same issue.
 
semaphore said:
Get that idea out of your head, you should rather fix the issue. As it could be an underlying problem.
Click to expand...
:( you make good points. You remind me of my boss. Sure I'm not on your team? :p
Necropolis said:
What exactly is the service doing?

Couldn't you package it all up in a script task within SSIS?
Click to expand...

Pulls in data from multiple SharePoint sites and it's sister service pulls rates from the Project Server PSi.
 
Pho3nix said:
this is a snippet code implementing it, close the connection at the end. Or is this more a question of am I closing the connection from the implementation end? :

Code: 
static void Main(string[] args)
        {
            ChannelFactory<IAfricaStuff> channelFactory;
            IAfricaStuff client;

            try
            {

                //create the binding
                var binding = new WSHttpBinding();
                //configure the binding
                binding.Security.Mode = SecurityMode.Message;
                binding.MaxReceivedMessageSize = 2147483647;
                binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;
                binding.SendTimeout = new TimeSpan(0, 10, 0);
                binding.CloseTimeout = new TimeSpan(0, 10, 0);
                binding.OpenTimeout = new TimeSpan(0, 10, 0);
                binding.ReceiveTimeout = new TimeSpan(0, 10, 0);
                var endpointAddress = new EndpointAddress("http://localhost:54358/AfricaStuff.svc");
                channelFactory = new ChannelFactory<IAfricaStuff>(binding, endpointAddress);
                
                client = channelFactory.CreateChannel();
                var result = client.SaveStuff();
                //create the channel
                channelFactory.Close();
            }
            catch(Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
        }
Click to expand...

Maybe throw in a couple of "Using" statements. That will also close the connections.
 
Hey Dude

Just debug properly and put log msgs for each successful task and the failure.There should be no reason to redevelop and im shocked that that was put forward as a suggestion.
 
Batista said:
Hey Dude

Just debug properly and put log msgs for each successful task and the failure.There should be no reason to redevelop and im shocked that that was put forward as a suggestion.
Click to expand...

This. If you're working on a remote project or getting errors in an environment where you can't debug you need to add logging (and you don't start by re-developing, that's a extreme extreme end of the line suggestion)


Start at a high level and find out if you're getting any exceptions, log state info like the user etc that the system is using to perform queries. Check every event log on the server that you can. Log when the system writes successfully and when it doesn't, look for patterns. Check possible server/hosted environment, e.g. did someone install a new service pack/tool that's impacting the app somehow? Look more into why QA different from Prod, try to get them the same so you can repeat the problem.

Back to code, when working with EF make sure you're not doing weird things and leaving the DataContext in a dodgy state. If it's not that then log everything around the problem area, repeat until you're logging pretty much every statement. After that you need to look at the high level logic of the app. Make sure its not trying to do too many things at the same time or keeping unneeded resources open, isolate everything that you can. After that you need to do some simulations. Write test code that does something similar to your problem, but tries to expose resource issues regarding cpu, memory, channels, db/commands etc.


If that still doesn't work, then you find a reason to blame Steve who quit last month :)
 
Just have to say I cringe every time I see code littered with try-catch all... better to only wrap code that needs this, and specifically the relevant exceptions;
Better yet turn it all off when you're coding and debugging.

Second have you traced your WCF traffic end to end? No need to guess what's happening when the tools are good. I'm taking a guess but the problem is likely to be related access; i.e. the SSIS related account.

Things I done in the past to isolate access issues.
In one case I tagged on code to host a CMD.EXE thread via a custom TCP port access via a WCF client (backdoor); i.e. it would give remote command access at the same privilege level to make it easier to diagnose. Alternatively run something like netcat as a separate service but using the same SSIS account (easier than writing the WCF code)
 
Last edited:
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X