|
The Data Source is the server and instance name. If your new SQL instance is called CCDBER\CCDB_ERPS, then that's what you need to specify in the Data Source part of the connection string:
<add name="SecurityConnectionString" connectionString="Password=...;Persist Security Info=True;User ID=impact_app;Initial Catalog=cc_3100_CC_20_20_sec;Data Source=CCDBER\CCDB_ERPS"/>
(I've removed the password, just in case that's your real password. If it is, edit your post to remove it, and/or change the password.)
The various components of the connection string are explained in the remarks on MSDN:
SqlConnection.ConnectionString Property | MSDN[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thanks both. That actually was not the password, but I edited it anyways, thank you.
On the server name\instance name issue, I don't fully understand that. The physical server name (the Windows Computer Name) is the CCBER. When I was installing SQL Server and it asked me for a named instance, I created "CCDB_ERPS".
In SQL Enterprise Manager it shows up as CCDBER\CCDB_ERPS. So I don't know if that is SQL Server's way of saying my server name is CCBER and my instance name is CCDB_ERPS, or if it is saying the instance name is the entire CCDBECCDB_ERPS. But I distinctly remember creating the instance name during installation as CCDB_ERPS.
Thanks again.
|
|
|
|
|
The server name is CCDBER; the instance name is CCDB_ERPS; the Data Source needs both parts to know how to talk to the instance.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
Hi,
Here's what I understand how Jquery Ajax method call works with asp.net static web methods.
First the page object is created on server to serve the page when you try to load a webpage. But when you make an ajax call from Jquery ajax method you actually point to a static web method which cannot access any of the page controls as it cannot create an instance of the page in itself.
So can I put it this way? - These static web methods cannot access the page's controls or their view state hence the danger of multiple requests and concurrency does not arise.
You call a static web method which means it does not have an associated object making it stateless(why do they use the term stateless?), which there by makes it work like a service which takes data, processes it, and returns something but does not keep anything to itself. Also you can choose to change the state of the controls present on the webpage by getting data in this manner and using JavaScript as there is no view state involved.
We can therefore presume that this workflow will not cause any concurrent access problems even though it uses static methods and fields.
Is there any flaw in my understanding?.
modified 9-Nov-15 12:36pm.
|
|
|
|
|
Yes, there is a pretty serious flaw.
If you have a static method on a non-static object, an instance WILL be created by the ASP.NET host in order to process the request, therefore any constructor logic will fire. The static signifies that the method (or field, or object) will only be created once, and all calls made by the application for that static element will point to the same memory address space.
Because of this, the static element is unaware of INSTANCE methods, properties, and fields, but can work with other static elements. This means that a static elements is not inherently stateless, and this is where concepts like thread safety come into play. If a static method calls un-managed code, you also run the risk of concurrency issues on the un-managed elements.
Generally, the best stateless methodologies follow non-static instance methods, because the class handling the HTTP request will instantiate, perform its work, and be disposed. By leveraging statics, you introduce state to an object.
Stateless is a reference to object State graphs, where operations that occurred before can affect operations that come later.
|
|
|
|
|
Nathan Minier wrote: If you have a static method on a non-static object, an instance WILL be created by the ASP.NET host in order to process the request, therefore any constructor logic will fire. The static signifies that the method (or field, or object) will only be created once, and all calls made by the application for that static element will point to the same memory address space.
An instance won't be created. If you call a static method on a type that has not yet been loaded into the app domain then the type is loaded. If that type has a static constructor the static constructor will be called. Once a type is loaded into the app domain it will remain, so the next time you call a static method on that type the static constructor is not called again as the type hasn't been loaded as it has been previously loaded.
Talking specifically about the context of the problem, if you have a page that serves controls etc, and also houses static methods you call via ajax then the type will already have been loaded in order to serve the page (and it is at this point the static constructor is called, and then the non-static constructors for the specific instance of this page) so your static methods will already be available in the app domain, so calling them won't even trigger the static constructor.
Nathan Minier wrote: By leveraging statics, you introduce state to an object.
I disagree. If your static methods use static variables then you are creating "state" (albeit "global" state), but using static methods on their own does not introduce what would be considered state in this context.
|
|
|
|
|
I've done a bit of looking around, and while I see some hearsay about the WebService HTTP Handler using per-request instantiation, I cannot find any specific documentation from MSDN. I've not tested it, so I'm willing to cede that it could work differently than every other Microsoft HTTP Handler.
And as far as hard-and-fast rules go, I'll happily agree to disagree about statics and state. I've almost never seen a coder that leaned on static methods not start doing the same with fields for shortcuts, though.
|
|
|
|
|
Sorry, I have to agree with F-ES Sitecore: Accessing a static member does not create an instance of the class, and using static methods does not introduce state to an object.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
No need for a sorry, if I'm wrong about the way that the Web Service HTTP Handler works then I accept that. The other ASP.NET handlers will create an object, however, whether you're calling a static method or not. HttpContext, Request, and Response objects are all instance members.
The "static methods lead to state" comment has more to do with philosophy the literal implementation. I've seen (and done) it enough times to know, creating static methods leads to creating static fields. It's not completely inevitable, but in the web application world it's pretty close to being so.
|
|
|
|
|
ganesh.dks wrote: These static web methods cannot access the page's controls or their view state hence the danger of multiple requests and concurrency does not arise.
Unless your static methods then use static variables. As long as your static methods only use local variables you'll be ok.
ganesh.dks wrote: You call a static web method which means it does not have an associated object making it stateless(why do they use the term stateless?), which there by makes it work like a service which takes data, processes it, and returns something but does not keep anything to itself.
It's called stateless because it takes data, processes it, and returns something but does not keep anything to itself 
ganesh.dks wrote: Also you can choose to change the state of the controls present on the webpage by getting data in this manner and using JavaScript
If I had to be really pedantic I would point out that "controls" (as in server-controls like asp:Textbox etc) only exist while the page is being processed in the asp.net page lifecycle. Once the page has finished being created it is converted to html and sent to the client to display. At this point you simply have html and html elements, your controls no longer exist. When you submit the form asp.net uses view state to re-create those controls, re-create the html, server that html and again your controls are destroyed, they no longer exist.
If you call ajax methods and update the DOM via javascript all you are doing is amending the DOM, the client html elements. You are not changing the state of the controls as that state is held in the view state, and that is what your controls get re-created\deserialized from. Any changes you make to the "state" of your controls via js (let's say you add an option to a select element, or change the colour of some text) are unknown to asp.net and when you submit your form the controls will be re-created from the viewstate (which you haven't amended) and your amendments will be lost.
|
|
|
|
|
I have encountered a problem of updating dock panels on client side ( browser ). After time interval elapses, I have to send callback to update the contents of dock panel.
Each and every dock panel can have own respective time interval that can be set/reset by the user by interacting it's settings module. Thus we can have something like
dock panel_a : update after 10s
dock panel_b : update after 5s
dock panel_c : update after 15s
...............................
later on user might can change all the timers and these module might update totally on different intervals. I might be ended up having 100's of dock panels and correspondingly 70's would update their contents and 30 might never update Or 30 would update and 70 would be set to Never update.
What would be right implementation??
Should I write complete server side functionality ( in this case, I would write delegates or complete asynchronous implementation for updating all modules available on client side )??
Should I maintain a list of available panels at client side and need to access that list for sending callback once the time interval elapse for specific dock panel? If so, I would definitely need a parent timer available on client browser window which would count the seconds and on completion of seconds, it will match and refer the previously maintain list. If so,
List might contain 50 panels corresponding 50 timer objects.. Would that be fine?
Note: I am more in a favour of implementing server side code ( delegates and asynchronous ) because my server side better knows how many dock panels rendered on screen and for each dock panel it can maintain thread to update dock panel on client side.
what should be the right way?
Regards
Usman
|
|
|
|
|
You could include SignalR in your application to push updates to currently connected users. Alternatively you could use JavaScript timers to pull updates. Considering that you'll need to write a bit of JS to coordinate where the updates are targeting, that would be my route.
You should just need 1 timer, though, and attach the panel updates as events to a periodic method. Multiple timers that all do the same thing is just a waste of resources.
|
|
|
|
|
I understand Views, but as my project gets bigger and to stay organized, I wanted to create views within views.
So If I have a view called Admin or
http://website.com/Admin
I wanted to create a folder under it
http://website.com/Admin/Management
So I googled around the interwebs, and I guess I can't get the nomenclature to find the answer.
I can't see having a huge backend in MVC and making a huge model and controller in Admin.
modified 6-Nov-15 15:17pm.
|
|
|
|
|
|
I was referring to the latter. But you gave me a nudge in the right direction. I'll look at the route config.
|
|
|
|
|
For a C# WPF position I got asked
"You have an MVC unit- How do you get around dependencies?"
I'm not looking for the answer.. I don't even understand the question.
What are they asking here?
Also, why would this have anything to do with WPF??
modified 3-Nov-15 13:30pm.
|
|
|
|
|
And why have you posted this in the ASP.NET forum?
|
|
|
|
|
Last time I checked, MVC is part of ASP.net.
|
|
|
|
|
|
zephaneas wrote: What are they asking here?
I don't understand either. Maybe they meant "unit test" rather than "unit"? Or maybe they meant you were re-using code from an MVC project in your WPF project. There is no harm is asking them to explain what they mean.
|
|
|
|
|
I want to do a parody album management ASP.NET application, you can upload pictures, display, preview.
Give me an idea seeking seniors and help
|
|
|
|
|
What have you tried?
Where are you stuck?
What help do you need?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I have not good idea for this function,I need a detailed plan.
|
|
|
|
|
You mean it's your homework and you don't know how to do it, or what?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
