Hello All,
I have a question about how to handle exceptions. Iam working on an
ASP.NET application which has a presentation layer, Business Layer and
DataAccess Layer. Iam confused about where to handle exceptions. Say
forexample I have a requirement where certain value has to be between
30-72 only and Iam doing this validation in the the BL. if the value is
not between 30-72 then Iam throwing an exception back to the UI layer.
Is this the right way to do or should I just check for the value and
use some variable or something to inform UI layer about the invalid
value.
Since it is a business requirement i thought of throwing an business
exception. Basically Iam confused to differentiate between a business
exception and a normal validation. what kind of exceptions should be
tried and caught and thrown in the Business Layer? Can someone please
help me solve this confusion?
Thanks
Jack
28  2052 
in DAL, encapsulate SqlException vs. to a DALException (your own type) and
throw it. in BOL do call validation method in the Save() method, if it fails
throw an BOLException, with appropiate message and if there is additional
info, inherit from BOLException and add properties for additional info about
error. line
ValueOutOfRangeException : BOLException
{
private int minValue;
private int maxValue;
...
...
}
and dont forget, you have to validate user input in your gui code too. even
you have to validate data with javascript. you cant escape in your gui code
from business rules. so, i recommend add validation functionalty to your BOL
only if 3rth party clients and/or other kinds of GUI apps (like winform,
mobile apps etc.) are using the same BOL dll/service app....
there is a better option (in my oppinion) checking such constraints in db
(adding constraints to your table). and do the rest in BOL/GUI.
and you may want to inspect "Exception Handling Application Block"..
If Iam not wrong you are saying that I should validate my Business
Rules in the UI layer and Check if those validations hold good in the
BL and throw exceptions to UI layer if I find any exception to the
rule. Or Do i need to do the validation in both UI and Business Layer?
If Iam doing validation in both UI and BL then Iam duplicating the code
isnt it?
Alsoo throwing the exceptions from BL is any business rule is not
satisfied is a good practice or not?
or is there any other accepted pattern for it??
First of all, exceptions should generally be reserved for exceptional
situations. In your case, you should have evaluation methods in your
business class that use return values (and other return information) to
indicate invalid input and the nature of the problem. Here is a
back-of-the-envelope design:
Your UI layer is designed to catch whatever errors it can on the client
side. On the Web, that's not much, but it does whatever simple checks
are available in the controls you're using.
Your business layer offers validation methods that your UI layer can
call to completely validate the data. These methods do _not_ throw
exceptions: they are part of the everyday functioning of your
application. Validation errors are _not_ "exceptional."
Your business layer offers methods to update your data layer. You may
then choose to do validation in your data layer as well. This
validation _does_ throw exceptions for invalid data, because invalid
data in your data layer means that your business layer is _broken_, and
that _is_ "exceptional."
Whether you put data validation in your data layer really depends upon
how loosely or tightly you want to couple the two layers. Data
validation in your data layer basically says that you don't trust your
business layer to validate everything. You are, in essence, firewalling
your data layer against errors in your business layer. Perhaps because
your data layer is a Web Service and doesn't know (or trust) who is
calling it. Or, perhaps because it was written by a different
programmer, and you're trying to guard against miscommunication. Or,
maybe you just want the warm, fuzzy feeling that comes from
double-validating your data and thus ensuring that it's rock-solid. In
any case, if you validate in your data layer, your data layer should
throw exceptions back to the business layer, effectively saying: "You
passed me bad data. You screwed up. You're broken."
Your business layer, on the other hand, should never throw an exception
back to the UI, unless the UI passes it totally the wrong thing (a null
reference, for example), meaning that the UI layer has a programming
error in it. For any invalid junk that the user can possibly introduce,
the BL should offer a validation method that returns info about what
went wrong via arguments / return value. (For example, I have methods
that return error messages. A null return means valid data.)
> Your business layer offers validation methods that your UI layer can call to completely validate the data. These methods do _not_ throw
exceptions: they are part of the everyday functioning of your
application. Validation errors are _not_ "exceptional."
if a deactivated customer is making an order, then this is an exceptional
case as if its a null customer reference.
Your business layer offers methods to update your data layer. You may
then choose to do validation in your data layer as well. This
validation _does_ throw exceptions for invalid data, because invalid
data in your data layer means that your business layer is _broken_, and
that _is_ "exceptional."
validations in data layer cant go far from simple lenght checks or id > 0
checks.. how much is necessary ?
>> Your business layer offers validation methods that your UI layer can call to completely validate the data. These methods do _not_ throw
exceptions: they are part of the everyday functioning of your
application. Validation errors are _not_ "exceptional."
if a deactivated customer is making an order, then this is an exceptional
case as if its a null customer reference.
That depends. If your UI is set up to prevent the user from entering
inactive customers,
but they manage to enter one anyway, then this is an exception: your UI
layer is
broken. That's exceptional. If, however, the user can type in any
customer number they
like, and they happen to type in the number of an inactive customer,
then it is not an
exception.
In the latter case, you would provide a method on Customer, like
IsActive, and check
that and provide feedback to the user.
Any condition that the user can provoke is not an exception, by
definition. An
"exception" occurs only when the system does not function as expected,
or a
condition arises that clearly indicates that some part of your program
is not
functioning as designed. Full disks, broken network connections, or
attempts on
the part of your program to do illegal things are all exceptions: they
are things
that are not part of the normal functioning of your program.
Your business layer offers methods to update your data layer. You may
then choose to do validation in your data layer as well. This
validation _does_ throw exceptions for invalid data, because invalid
data in your data layer means that your business layer is _broken_, and
that _is_ "exceptional."
validations in data layer cant go far from simple lenght checks or id > 0
checks.. how much is necessary ?
That depends upon how much firewalling you want to do, which in turn
depends (to some degree) on the design of your application. You can
design a data layer that totally trusts the business layer to do all
validation.
You can also design a data layer that trusts nothing else and validates
all conditions on all data.
Typically, loosely coupled systems validate more at each layer, because
each layer could be called by various, different higher-level layers,
and so there
is less trust. If you are writing a data layer that is going to be used
by sixteen
other programmers writing dozens of applications, then you probably
don't trust
all of them to correctly validate the data in every single one of those
business
layers, so you validate in the data layer, as a double-check on the
validation
that they're doing. Any discrepancy is an exception, because it
indicates incorrect
programming on their part.
Tightly coupled systems, like those that run as one application, or are
client-server using remoting, for example, often do less data layer
validation
because they trust the business layer to have already taken care of
the validation. If you're writing the whole app by yourself, and the
data layer
is only going to be used in the one app, then you may choose to do
little
or no validation in the data layer.
Personally, if I have time on a project I prefer more data layer
validation, because it's
free, constant unit testing of my business-layer code. If I make a
mistake
in the business layer, I get an exception in the data layer. It makes
me
feel more comfortable that my code is correct.
However, not everyone has the time and the inclination to duplicate
their
data validation. It all depends, as I said, on your architecture, on
project pressures, and on your programming style.
data validation is not business rule validation, you cant validate a
customer can give max 3 orders at the same time. my personal idea is, giving
the data validation responsibility to database. one more thing : when
someone calls persistance method of your entity, and there is a broken
business rule, will you simply return false? or do you inclue kind of "out
string errorMessage" parameters? what if the error message is not sufficient
and error includes additional information? what will you do? i think
inserting 4 orders for same customer at a time is a exceptional behaviour of
the system anyway.
Business layer validation should be at least as strong as, or stronger
than, data layer validation. If any data layer validation fails, it
means that the business layer did not do its job and there is a
programming error in the business layer, so an exception is the right
way to go here.
At least, this is one design. I have seen people do all validation in
the data layer, but I find that it makes error reporting to the user
unnecessarily difficult, because the data layer often doesn't
understand context well enough to return a meaningful message.
I have designed my error reporting like this:
1. The UI layer calls business layer routines to validate user input.
2. The business layer validation routines return strings--error
messages. A return value of null indicates valid data.
3. The error messages are designed to be shown to the user. This isn't
too hard, as the business layer understands the context of what the
user is trying to do and so can build good error messages.
4. Once the data is confirmed to be valid, the business layer attempts
to persist the data. It calls the data layer with the validated user
input, probably massaged into a form more amenable to the data layer.
5. The data layer may or may not validate the data again. I like to
validate it again, but not everyone does. Data layer validation is
necessarily a little weaker than business layer validation, because the
data layer pieces lack large-scale contextual knowledge about what's
going on. A data layer object that stores Suppliers probably doesn't
know that the large-scale operation is to create a PurchaseOrder for a
new Supplier. The data layer checks what it can (usually fine-grained
stuff like valid field values and valid foreign keys).
6. If the data layer finds a problem, it _throws an exception_, because
its finding a problem means that the business layer failed in its job
to completely validate the data and inform the user of any problems,
_or_, something is broken in the data store itself. In either case,
this is a _failure_ of the app, not a result of something the user did,
so it's an exception.
7. The exception message from the data layer is probably extremely
detailed, including stack traces, etc. It is not meant to be seen by
the user. It should be logged somewhere and the user informed that
there was a "Failure" and to call support.
what if GUI forgets to call validate? i think u keep a private member
variable like bool isValidated and check in the persistence method. but it
adds too much code, every setters must set isValidated to false... whatever
its an exception or not, because throwing exception is more simple, i will
prefer throwing exception.
If the UI forgets to call validate then it's a coding error in the UI
and the business layer or the data layer throws an exception.
how can you understand ui forgeted to call validate? dont misunderstand me,
i just wanna pick up something from you.
Most business layers have some sort of commit, save, update, method...
whatever you want to call it, for each business object. A method that
says, "OK, I'm done making changes, now persist this object to the data
layer."
That method should repeat all of the validation, even if you've been
validating each field as the user types in it / chooses from it. If you
architect the business layer properly, this is nothing more than a list
of method calls to call the same validation methods that the UI layer
used.
Usually you have to have validation in this commit / save / update
method anyway, as there are inter-field checks that can't be done by
the UI when the user is modifying individual fields. For example, there
is a "Minimum" field and a "Maximum" field. The UI's individual field
validation can verify that they are both valid numbers within range,
but individual field validation usually wouldn't verify that Minimum is
less than Maximum. Usually you do that only at the moment you're about
to persist the data.
So, as part of these checks that are usually done just before
persisting the data, you just repeat the individual field checks again.
Like I said, a few extra method calls.
If any of the individual field checks fails, then that's an exceptional
circumstance: the UI should have caught those as the user was entering
data, and the business layer method should throw an exception
indicating that the UI is broken.
If any of the inter-field checks fails, then that's normal: the
business layer's "persist" method should take the resulting error
string and display it to the user. You can use an ErrorProvider (if the
problem can be isolated to one or two fields) or pop a dialog box. In
my example above, if Minimum is greater than Maximum, the business
layer would take the error string, something like "Minimum 15 is
greater than Maximum 4." and display it in an ErrorProvider next to
both the Minimum and Maximum fields. On the other hand, if Minimum is
-100, and only positive values are allowed, then the business layer
throws an exception, because the UI should not have allowed the user to
type in a negative number.
This is just an example: how you divide the validation between the UI
layer and the business layer is up to you, and depends upon how much
your UI can do for you. Web forms are, of course, more limited in their
client-side capabilities than Windows forms are.
If the business layer's persist method (save, update, whatever, ...)
concludes that the user's input is valid, then it calls the data layer
to persist it.
The data layer may choose to do additional checks. If any of these
fails, then the data layer throws an exception, because its "user" is
the business layer, and it expects the business layer to send it only
correct data.
Bruce... Although I may agree with your use of exceptions I don't agree
with
the statement that exceptions should generally be reserved for
exceptional
situations. One person's exceptional situation is another person's
routine
condition. See the works of Abraham and more recently Herb Sutter on
this
subject.
IMHO, if the caller violates an explicitly stated pre condition or
invariant of a
method then the method should throw an exception if the precondition or
invariant is violated. By explicitly stating the preconditions, you
allow the
caller the choice of validating for preconditions or catching
exceptions.
Now things get complicated. Given that an API provides a method to open
a
file, that throws an filenotfound exception and supplies a fileexist
method.
The common answer is to check if the fileexist and open the file or just
try to
open the file and trap for an exception. In a single threaded, single
user
environment the first approach may be best. But in a multithreaded or
multiuser environment where a second thread might delete the file
between
the two calls the second approach may be better.
A concrete example is an abstact class AccountBase with thread safe
withdraw and deposit methods that take only values >0. If the methods
explicitly state that the parameter must be >=0 then the method should
throw an exception if the caller violates the precondition, otherwise it
should
return an error. However, it is not possible to know if a withdrawal
amount is
valid except in the critical section since two threads could be
withdrawing
"almost at the same time" so it is not possible to guarantee the
precondition
that withdrawal >= balance outside of the critical condition. So the
method
may not want to declare such an invariant and just return false.
Finally, the
method could explicity declare the invariant that withdrawal <= balance
and
throw an exception if the invariant is violated. This would require that
the
caller trap for exceptions in a multi-threaded environment.
So, what is exceptional here? Hard to tell. The practical approach is to
explicitly state the preconditions and invariants that could result in
an
exception and to throw an exception when an explictly stated pre
condition
or invariant is violated.
Regards,
Jeff
*** Sent via Developersdex http://www.developersdex.com ***
one more thing : ive seen lots of articles in msdn or books (some of them
was from ms publishing) suggesting throwing exceptions in property setters
like this :
public string Name
{
get{return name;}
set
{
if(value.length > 15)
throw new ArgumentException("Name's length cannot be more then
15");
name = value;
}
}
You are correct. In this entire discussion I am talking about
single-threaded situations. As soon as you introduce the possibility of
race conditions between multiple players, the validation in the
business layer becomes more complicated, and may in fact require an
attempt to call the data layer to persist the data whilst trapping any
exceptions, as you pointed out.
Even in these situations, however, I see no reason why simple
syntactic-level validation should throw exceptions. There are lots of
simple tests that don't change when you move into the multi-user world,
and those tests should offer the possibility of calling a validation
routine rather than having to handle an exception.
gui is not responisble to check for valid values, or rather gui dont have to
validate data because we know nothing about gui. it can be
webform/winform/mobile phone/refrigerators display screen. so if gui didnt
validate data, its not an exception according to your idea.
This gets into a very interesting area of discussion that really
centres around how you see your business objects. So far I've come up
with two points of view.
1. A business object always maintains valid internal state. Any attempt
to set a business object property to an invalid value, whether that
value is syntactically invalid (as in your example) or semantically
invalid in the context of other properties, is an exception.
2. A business object can maintain invalid internal state, and has a
validation routine that informs the caller of whether it is in a valid
state. Any attempt to persist a business object in an invalid state
results in an exception.
The immediate difficulty with definition #1 is that it makes it very
difficult to use business objects as backing information for UI forms.
In the process of filling in forms, users often have the business
object data on the form in an inconsistent state, and in fact the user
experience is truly nasty if you insist that the user only change the
form from one valid state to another. So, the UI has to be able to
"free wheel" a bit and support transient invalid states. Really, the
only time you want to be absolutely sure that you have a valid business
object state is when the user presses "Save". So... what to use as a
model object behind your form? An anal retentive business object that
always insists on coherent state doesn't seem to fit the bill.
However, choice #2 yields even worse results. Now we have a business
object that supports incoherent state, and has a validation method to
inform the user of any problems, but the fact that the business object
supports invalid states makes it next to useless as a real business
object. The whole point of business objects is that they throw
exceptions when callers try to mangle them: that's what business rules
are.
I solved this problem by writing an extra class for my BusinessObject
class: a BusinessObjectValidator. The BusinessObjectValidator acts as a
model behind the UI form. It will accept pretty-much anything in any of
its properties, and send events back to the UI if the user types
something invalid. It handles all of the connections between, say, the
user changing property A which results in a change to property B. Every
property has an XxxxChanged event associated with it. In short, the
BusinessObjectValidator (one for each business object) is designed to
be a UI model. It also does all of the validation.
The BusinessObject is then a pure business object. Being one layer
down, it throws exceptions for invalid property values. It's very
picky, and insists on maintaining a coherent internal state. Throwing
exceptions here is entirely reasonable: the user doesn't direclty
manipulate this object... instead, the user manipulates it through the
corresponding validator. If any field of a businesss object is set to
an invalid value, it's because the corresponding validator has a bug in
it and so it _is_ an exception.
In additional to the plumbing for individual fields, the validator also
has a BuiltObject property that returns a properly constructed business
object _if_ the current state of the validator is coherent. When the
user presses Save, the UI calls the validator's SaveErrorMessage
property. If an error message comes back, it shows that to the user; if
no error message comes back, then the UI is free to call BuiltObject
and get a real business object back, because the validator (model)
contains coherent information that could be used to successfully build
a business object.
Yes, it's more coding, but out of it I get a picky business object that
insists on coherent internal state, and throws exceptions if callers
try to mess that up, and a business object validation object that acts
as a backing model for maintenance forms, etc., and provides a rich
interactive experience for the user. The business object is exactly
what you want for all business operations, because you know that its
internal state is 100% correct. The validation object allows the user
to make mistakes and recover from them. The business object throws
exceptions. The validation object provides methods to test for invalid
data, and typically doesn't throw exceptions.
if u write your businness-data layers compatible to only winform, then its
not 3-tier architecture. and those tests should offer the possibility of calling a
validation
routine rather than having to handle an exception.
can you give an example where gui can just keep on running without handling
unsuccessfull validation result?
Well, note that I say UI everywhere, not GUI, and don't forget that
even with Web front ends and Compact Framework implementations you can
still design components that will do rudimentary things like check to
make sure that input is numeric, or check that a number is within a
given range.
Even if you're programming for the lowest common denominator, which
right now is WebForms, and insist that your actual GUI do nothing at
all, you still often have a UI layer on the server side that does some
rudimentary syntactic checking on postback before calling the business
layer. Note that I say "UI" everywhere, not "GUI". I agree, however,
that the dividing line between the "UI" and the "business layer" is
often a matter of opinion and taste.
> if u write your businness-data layers compatible to only winform, then its not 3-tier architecture.
Sure it is. Smart clients use WinForms and they're three-tier.
Client-server apps that use remoting can use WinForms, and they're
three-tier. Lots of applications have no need for a Web presence. You
might argue that they're not as flexible as they could be, but they're
certainly multi-tier. Read some of Rockford Lhotka's stuff on
multi-tier architectures... he goes into this in some detail.
Web applications are, in fact, often four-tier: the browser, which is a
very thin GUI, with a backing UI layer on the server to handle
validation and suchnot, followed by a business layer, and a data layer.
I'm not sure I understand your second question, but perhaps it would
help to point out that a UI layer can _forget_ to call a validation
routine... all it has to do is omit the call. It can then cheerfully
pass garbage to the business layer and say, "Here... persist this for
me." In that situation, the business layer should throw an exception.
The UI layer should have asked politely whether the business object was
OK before trying to persist it.
Now, as Jeff pointed out, in a multi-user environment some tests can't
be done as validate / persist pairs because of race conditions, but
that doesn't mean one should abandon the idiom completely just because
you have to do something else in some situations.
we dont live in stone age, there is almost no "not graphical" but User
Interface type. users dont interact with applications via mors alphabet sort
of things.
after save button is pressed, you retrive a coherent business object. and
what do you do with it? who changes its properties? do you just call Save
method and leave it?
Crow... Then I would argue that you must explicitly state the
precondition.
// ASSERT value.length >15
public string Name
{
get{return name;}
set
{
if(value.length > 15)
throw new ArgumentException("Name's length cannot be more then
15");
name = value;
}
}
Regards,
Jeff
*** Sent via Developersdex http://www.developersdex.com ***
no i meant, after ui call Validate() and not a null value returned, ui %99
will take an action. and those tests should offer the possibility of calling a
validation
routine rather than having to handle an exception.
you have to deal invalid conditions, whether an exception is thrown, or
Validate returns not a null value.
Well, in the case of one of my applications, which maintains
information for our company, the Save method persists it to the
database. I then include it in my local cache of valid objects. I could
equally well have reloaded that list from the database, but for speed
reasons I don't do that in this app.
If the user then wants to edit the object some more, I pass the object
back into the corresponding validator, which raises events back out to
the UI layer to set up the UI fields with the correct values. Then the
user is back interacting with the validator again until they press Save
again to update the business object.
Really, you could argue that the validator isn't a business layer
object at all... that it's really a UI layer object that knows how to
build and modify business objects. I wouldn't argue with that
interpretation. However, the interaction between the two is still that
the UI chants back and forth with the business layer, asking whether
individual values and relationships between values are OK before trying
to create a real, honest-to-goodness business object, and throughout
the entire process the only exceptions that are thrown occur if the
database update failed, or some other exceptional condition arises.
i realy dont understand you. u seem to create an object just for pickup
values from user for the first time. then you use another object after
record is inserted. this message thread is going to be conservation. maybe
its better to talk in messenger.
No... the user always interacts with the validation object, whether it
is to create a new business object or modify an existing one. The
validation object is, in effect, the UI model. It is responsible for
mediating between the chaotic UI and the orderly world of the business
object.
> you have to deal invalid conditions, whether an exception is thrown, or Validate returns not a null value.
Yes, but exceptions often aren't rich enough to return detailed
information about what went wrong, the kind of information tailored to
what would be meaningful to a user. Exceptions were designed to carry
detailed information about what was going on inside the software when
the failure occurred, which is precisely what is not interesting to the
user, and in many cases precisely the user shouldn't see... see books
on security such as Microsoft's Writing Secure Code: http://www.amazon.com/exec/obidos/tg...glance&s=books
So, you have to catch a particular exception, and then as a programmer
you have a problem: either the exception message is designed for the
user to see, or you have to parse the error message to figure out what
went wrong, or you have to make lots of exception types so that you can
distinguish different errors, or you just give some lame message like,
"Invalid salary." It gets messy because you're using one type of
failure communication-exceptions-to transmit both errors that the
user made in entering data _and_ failures within the system, so at some
level you have to tease those two apart and take appropriate action in
each case. This isn't such a chore in specific routines, such as the
one that tries to translate the annual salary from text into a monetary
value, but becomes tedious (and error-prone) if you just toss a mass of
exceptions up to the UI and say, "Here, UI, you sort this out."
By using two different mechanisms for signalling errors, you make
things clearer, I think: error return values indicate that the user
made a mistake and should be informed; exceptions indicate that the
system is broken, or at least something is failing internally, and they
should be logged for later analysis by programming staff.
And yes, sometimes in the bottom UI layer (or the top business layer,
however you want to think of it), you have to transform exceptions into
error messages, because lower-level routines don't understand the
context and throw exceptions. Even there you can often provide
validation routines that you can call before attempting an operation to
see if it will succeed. Notice that the Framework does this: it
provides, for example TryParse methods so that you can check to see if
a string is a valid representation before actually trying to parse it.
Even if you can't, and have to deal with an exception, you transform it
into a meaningful error messages as soon as you can, so that higher
levels don't have to distinguish between this exception (which is a
message for the user) and other exceptions (which indicate application
failure).
My point, though, when all is said and done, is that the code is
clearer and easier to manage if you avoid bubbling exceptions up to the
UI and forcing it to distinguish between system errors and user
mistakes; it's tidier to have two error vectors: error messages for bad
input, and exceptions for true failures. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Steve O'maley |
last post by:
I currently have the Exception Management Application Block working in my base directory, but when I create pages in a subfolder the Exception Management Application Block is never executed. The...
|
by: Abelardo Vacca |
last post by:
Hello,
I am currently in the process of switching our application to a N-Tier model
with .NET.
One of the aspects we want ot get right from the start not to worry about it
after is the...
|
by: Páll Ólafsson |
last post by:
Hi
I have a problem with the Microsoft.ApplicationBlocks.ExceptionManagement? I
can't get it to work in RELEASE mode? If I run the project in debug mode
the block works fine but when I run the...
|
by: Scott Brady Drummonds |
last post by:
Hi, all,
I've a fairly small piece of code that is causing me problems. I'm using
std::string and am building a string of several dozen characters using
several of std::string's functions: a...
|
by: PCC |
last post by:
I am using the Exception Managment Application Block on Windows Server 2003
Enterprise and .NET v1.1.
If I use the block with an ASP.NET web wervice or in a web application I get
the following...
|
by: craig |
last post by:
I am wondering if there are some best practices for determining a strategy
for using try/catch blocks within an application.
My current thoughts are:
1. The code the initiates any high-level...
|
by: leodippolito |
last post by:
Hello,
I have these entities in my ASP.NET application:
- data access layer (DATA)
- custom exception class (EXCEPTION)
- cache management class (CACHE)
They're all built into different...
|
by: SQLJunkie |
last post by:
Hi,
I have installed SQL 2005 RTM on a new server and I keep getting this
error (described below) quite frequently. Was wondering if anyone has a
clue on what's happening here. I tried googling...
|
by: KaNos |
last post by:
Hello world,
I've made a webservice (c# v2) to install in a server IIS 6 on a Windows
2000 last SP. We can use the webservice in local, throw the pages wich
present the methods, with a windows...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
