473,323 Members | 1,550 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,323 software developers and data experts.

best practices on the creation of webmethods

Hi,

I was wondering if there are any best practices on the creation of
webmethods? I'll try to explain this a little more:
My problem is that we are changing an existing (large) DCOM application to
use web services, but we have like hundreds of different methods you can
call and what I wanted to do, is add a couple of generic webmethods that
take a serializable .NET class or structure, and in that class or structure
we put all the necessary information about the action that must be
performed. I would think this is a lot easier instead of adding all the
different methods, but my question is, if that is recommended to implement
this in such a way? If not, is it then recommended to add one service with
all these method, or is it better to split it up in different services? Is
there a recommended maximum of webmethods for one service?

I have to add that the web service will only be used internally, I mean that
normally no other company will use our web service (we create the client
application).

Any thought or suggestions are welcome.

Thanks,
Bert
Nov 23 '05 #1
14 2579
Bert Vandenberghe wrote:
we have like hundreds of different methods you
can
call and what I wanted to do, is add a couple of generic webmethods
that
take a serializable .NET class or structure, and in that class or
structure
we put all the necessary information about the action that must be
performed.
How would you handle each logical operation if not as a separate method?
I mean, you could go with some kind of command pattern and build some custom
routing, but why not leverage the frameworks that already exist for routing
the messages to the right methods and keep it broken up that way (ASMX or
WSE)?
I would think this is a lot easier instead of adding all
the
different methods, but my question is, if that is recommended to
implement
this in such a way?
I don't think it's easier at all. If anything you're going to make it harder
for people to consume because your generic approach, while perhaps infinitely
extensible, has to lack type specific details that make it harder for a caller
to understand what information is necessary for any given operation. For
example from a pure XML perspective your method would really just need to
take xsd:any and then people would have to go figure out what message they
want to send you and what parameters make up that method as opposed there
being four parameters directly on the method that they just need to pass.
If not, is it then recommended to add one service
with
all these method, or is it better to split it up in different
services?
You should probably break up the services based on some logical grouping
of operations. For example, if you had user management and order management
aspects, you would have two different services (UserManagementService OrderManagementService)
each with N methods for dealing with specific types.
Is
there a recommended maximum of webmethods for one service?
There is none, but like I said you'll probably want to break things up logically.
Think of it like the Win32 API. There's tons of methods in the Win32 right?
But when you want to do draw something to the screen you know where to go:
GDI. Now, there's still a ton of methods in GDI, but you know they're all
related in some way to drawing.
I have to add that the web service will only be used internally, I
mean that normally no other company will use our web service (we
create the client application).


Internal or external I still think it's in your best interests to design
it the way I've discussed above. Designing web services APIs is really are
no different than any other type of API design when it boils down to it.
You still want to avoid creating a monolithic frankenstein.

HTH,
Dre

Nov 23 '05 #2
Hi Bert:

If your distributed application is going to be used internally, you will be
better off by using .NET Remoting. Incase you do want web services try and
make your API chunky rather than chatty (that is, few web methods that each
do quite a bit is better than having lots of web methods that do one very
granular piece of functionality). Also, if you are using web services (and
not .NET Remoting) for the reason that you may change your client
environment someday, you should make your service compliant to WS-I Basic
Profile 1.0.

Thanks,
Mujtaba.

"Bert Vandenberghe" <en*********@hotmail.com> wrote in message
news:eo**************@TK2MSFTNGP09.phx.gbl...
Hi,

I was wondering if there are any best practices on the creation of
webmethods? I'll try to explain this a little more:
My problem is that we are changing an existing (large) DCOM application to
use web services, but we have like hundreds of different methods you can
call and what I wanted to do, is add a couple of generic webmethods that
take a serializable .NET class or structure, and in that class or
structure
we put all the necessary information about the action that must be
performed. I would think this is a lot easier instead of adding all the
different methods, but my question is, if that is recommended to implement
this in such a way? If not, is it then recommended to add one service with
all these method, or is it better to split it up in different services? Is
there a recommended maximum of webmethods for one service?

I have to add that the web service will only be used internally, I mean
that
normally no other company will use our web service (we create the client
application).

Any thought or suggestions are welcome.

Thanks,
Bert

Nov 23 '05 #3
What I was planning to do, is creating a webmethod with one argument which
is actually a serializable class like this:

[XmlRoot("GenericMessage")]
public abstract class GenericMessage
{
public enum Action {ADD_THIS, ADD_THAT, EDIT_ANOTHER_THING, DELETE_THIS,
ADD};
public Action type;
....
}

Then it is also possible to derive other classes from this one with more
specific information about certain action and use it with the same
webmethod, e.g:

public class AddSpecialMessage : GenericMessage
{
public string moreInfo;
....
}

But like you mention, this would not be so clear for an external user what
you can do with this method, but I still think it would be easier than
creating all the seperate methods, just if you want to change something to
one of the method, or add a method...

Maybe it is indeed better to create all the seperate webmethods, thanks for
the advice,

Bert

"Drew Marsh" <dr****@hotmail.no.spamming.com> wrote in message
news:10**********************@msnews.microsoft.com ...
Bert Vandenberghe wrote:
we have like hundreds of different methods you
can
call and what I wanted to do, is add a couple of generic webmethods
that
take a serializable .NET class or structure, and in that class or
structure
we put all the necessary information about the action that must be
performed.
How would you handle each logical operation if not as a separate method?
I mean, you could go with some kind of command pattern and build some

custom routing, but why not leverage the frameworks that already exist for routing the messages to the right methods and keep it broken up that way (ASMX or
WSE)?
I would think this is a lot easier instead of adding all
the
different methods, but my question is, if that is recommended to
implement
this in such a way?
I don't think it's easier at all. If anything you're going to make it

harder for people to consume because your generic approach, while perhaps infinitely extensible, has to lack type specific details that make it harder for a caller to understand what information is necessary for any given operation. For
example from a pure XML perspective your method would really just need to
take xsd:any and then people would have to go figure out what message they
want to send you and what parameters make up that method as opposed there
being four parameters directly on the method that they just need to pass.
If not, is it then recommended to add one service
with
all these method, or is it better to split it up in different
services?
You should probably break up the services based on some logical grouping
of operations. For example, if you had user management and order

management aspects, you would have two different services (UserManagementService OrderManagementService) each with N methods for dealing with specific types.
Is
there a recommended maximum of webmethods for one service?
There is none, but like I said you'll probably want to break things up

logically. Think of it like the Win32 API. There's tons of methods in the Win32 right? But when you want to do draw something to the screen you know where to go:
GDI. Now, there's still a ton of methods in GDI, but you know they're all
related in some way to drawing.
I have to add that the web service will only be used internally, I
mean that normally no other company will use our web service (we
create the client application).


Internal or external I still think it's in your best interests to design
it the way I've discussed above. Designing web services APIs is really are
no different than any other type of API design when it boils down to it.
You still want to avoid creating a monolithic frankenstein.

HTH,
Drew

Nov 23 '05 #4
Hi Mujtaba,

I hestitated for a long time between .NET Remoting and web services,
but I thought that it is be better to choose web services with the eye on
the
future (Indigo). But it would indeed probably be better for performance to
choose .NET Remoting.
Should I start hesitating again now after reading your message?

Thanks for your advice,
Bert
"Mujtaba Syed" <mu*****@marlabs.com> wrote in message
news:e%****************@TK2MSFTNGP14.phx.gbl...
Hi Bert:

If your distributed application is going to be used internally, you will be better off by using .NET Remoting. Incase you do want web services try and
make your API chunky rather than chatty (that is, few web methods that each do quite a bit is better than having lots of web methods that do one very
granular piece of functionality). Also, if you are using web services (and
not .NET Remoting) for the reason that you may change your client
environment someday, you should make your service compliant to WS-I Basic
Profile 1.0.

Thanks,
Mujtaba.

"Bert Vandenberghe" <en*********@hotmail.com> wrote in message
news:eo**************@TK2MSFTNGP09.phx.gbl...
Hi,

I was wondering if there are any best practices on the creation of
webmethods? I'll try to explain this a little more:
My problem is that we are changing an existing (large) DCOM application to use web services, but we have like hundreds of different methods you can
call and what I wanted to do, is add a couple of generic webmethods that
take a serializable .NET class or structure, and in that class or
structure
we put all the necessary information about the action that must be
performed. I would think this is a lot easier instead of adding all the
different methods, but my question is, if that is recommended to implement this in such a way? If not, is it then recommended to add one service with all these method, or is it better to split it up in different services? Is there a recommended maximum of webmethods for one service?

I have to add that the web service will only be used internally, I mean
that
normally no other company will use our web service (we create the client
application).

Any thought or suggestions are welcome.

Thanks,
Bert


Nov 23 '05 #5
Bert Vandenberghe wrote:
I hestitated for a long time between .NET Remoting and web services,
but I thought that it is be better to choose web services with the eye
on
the
future (Indigo). But it would indeed probably be better for
performance to
choose .NET Remoting.
Should I start hesitating again now after reading your message?


You can still get perfectly acceptable performance from Web Services, it's
all about the design. Also, for a quick performance gain in your case, you
can eliminate HTTP from the equation since this is for an in house application
and just use WSE2.0's soap.tcp protocol. The design of your web services
doesn't have to change at all and if you still wanted to expose them over
HTTP in the future you would just start hosting the same classes in ASP.NET
instead.

HTH,
Dre

Nov 23 '05 #6
Hi Bert:

As per the WinHEC drop of Longhorn, Indigo supports two types of services:
Indigo web services (which are next gen web services) and Indigo
RemoteObject services (which are similar in spirit to .NET Remoting).

Your problem is made to be solved by .NET Remoting since you are doing
distributed objects on a homogeneous network.

Thanks.
Mujtaba.

"Bert Vandenberghe" <en*********@hotmail.com> wrote in message
news:OT**************@TK2MSFTNGP09.phx.gbl...
Hi Mujtaba,

I hestitated for a long time between .NET Remoting and web services,
but I thought that it is be better to choose web services with the eye on
the
future (Indigo). But it would indeed probably be better for performance to
choose .NET Remoting.
Should I start hesitating again now after reading your message?

Thanks for your advice,
Bert
"Mujtaba Syed" <mu*****@marlabs.com> wrote in message
news:e%****************@TK2MSFTNGP14.phx.gbl...
Hi Bert:

If your distributed application is going to be used internally, you will

be
better off by using .NET Remoting. Incase you do want web services try
and
make your API chunky rather than chatty (that is, few web methods that

each
do quite a bit is better than having lots of web methods that do one very
granular piece of functionality). Also, if you are using web services
(and
not .NET Remoting) for the reason that you may change your client
environment someday, you should make your service compliant to WS-I Basic
Profile 1.0.

Thanks,
Mujtaba.

"Bert Vandenberghe" <en*********@hotmail.com> wrote in message
news:eo**************@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> I was wondering if there are any best practices on the creation of
> webmethods? I'll try to explain this a little more:
> My problem is that we are changing an existing (large) DCOM application to > use web services, but we have like hundreds of different methods you
> can
> call and what I wanted to do, is add a couple of generic webmethods
> that
> take a serializable .NET class or structure, and in that class or
> structure
> we put all the necessary information about the action that must be
> performed. I would think this is a lot easier instead of adding all the
> different methods, but my question is, if that is recommended to implement > this in such a way? If not, is it then recommended to add one service with > all these method, or is it better to split it up in different services? Is > there a recommended maximum of webmethods for one service?
>
> I have to add that the web service will only be used internally, I mean
> that
> normally no other company will use our web service (we create the
> client
> application).
>
> Any thought or suggestions are welcome.
>
> Thanks,
> Bert
>
>



Nov 23 '05 #7
Is using soap over tcp faster than over http? Otherwise it is indeed better
that we install WSE2.0 and that we use tcp instead of http. Thanks for the
tip.

And I think it is indeed more fexible to use web services, just in case a
customer wants to expose it on the internet, you never know...

Thanks,
Bert

"Drew Marsh" <dr****@hotmail.no.spamming.com> wrote in message
news:10**********************@msnews.microsoft.com ...
Bert Vandenberghe wrote:
I hestitated for a long time between .NET Remoting and web services,
but I thought that it is be better to choose web services with the eye
on
the
future (Indigo). But it would indeed probably be better for
performance to
choose .NET Remoting.
Should I start hesitating again now after reading your message?
You can still get perfectly acceptable performance from Web Services, it's
all about the design. Also, for a quick performance gain in your case, you
can eliminate HTTP from the equation since this is for an in house

application and just use WSE2.0's soap.tcp protocol. The design of your web services
doesn't have to change at all and if you still wanted to expose them over
HTTP in the future you would just start hosting the same classes in ASP.NET instead.

HTH,
Drew

Nov 23 '05 #8
Hi Mujtaba,

I was not aware of the 2 different types of services in Indigo, I'll take a
look at that, thanks.
But my choice for web services was based on a video I saw of Richard Turner
(Program manager of Indigo):
http://channel9.msdn.com/ShowPost.aspx?PostID=9990

If you take a look at it, you'll see that he is saying that you may only use
remoting when absolutely necessary, otherwise he advises to use webservices.

Thanks,
Bert

"Mujtaba Syed" <mu*****@marlabs.com> wrote in message
news:e4**************@TK2MSFTNGP09.phx.gbl...
Hi Bert:

As per the WinHEC drop of Longhorn, Indigo supports two types of services:
Indigo web services (which are next gen web services) and Indigo
RemoteObject services (which are similar in spirit to .NET Remoting).

Your problem is made to be solved by .NET Remoting since you are doing
distributed objects on a homogeneous network.

Thanks.
Mujtaba.

"Bert Vandenberghe" <en*********@hotmail.com> wrote in message
news:OT**************@TK2MSFTNGP09.phx.gbl...
Hi Mujtaba,

I hestitated for a long time between .NET Remoting and web services,
but I thought that it is be better to choose web services with the eye on the
future (Indigo). But it would indeed probably be better for performance to choose .NET Remoting.
Should I start hesitating again now after reading your message?

Thanks for your advice,
Bert
"Mujtaba Syed" <mu*****@marlabs.com> wrote in message
news:e%****************@TK2MSFTNGP14.phx.gbl...
Hi Bert:

If your distributed application is going to be used internally, you will
be
better off by using .NET Remoting. Incase you do want web services try
and
make your API chunky rather than chatty (that is, few web methods that

each
do quite a bit is better than having lots of web methods that do one
very granular piece of functionality). Also, if you are using web services
(and
not .NET Remoting) for the reason that you may change your client
environment someday, you should make your service compliant to WS-I Basic Profile 1.0.

Thanks,
Mujtaba.

"Bert Vandenberghe" <en*********@hotmail.com> wrote in message
news:eo**************@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> I was wondering if there are any best practices on the creation of
> webmethods? I'll try to explain this a little more:
> My problem is that we are changing an existing (large) DCOM application to
> use web services, but we have like hundreds of different methods you
> can
> call and what I wanted to do, is add a couple of generic webmethods
> that
> take a serializable .NET class or structure, and in that class or
> structure
> we put all the necessary information about the action that must be
> performed. I would think this is a lot easier instead of adding all
the > different methods, but my question is, if that is recommended to

implement
> this in such a way? If not, is it then recommended to add one service

with
> all these method, or is it better to split it up in different services? Is
> there a recommended maximum of webmethods for one service?
>
> I have to add that the web service will only be used internally, I

mean > that
> normally no other company will use our web service (we create the
> client
> application).
>
> Any thought or suggestions are welcome.
>
> Thanks,
> Bert
>
>



Nov 23 '05 #9
Bert,

One thing I try to design in my webservices is to reduce the need for round
trips to the webservice. So I attempt to rework some of my back-end methods
to reduce this. For example, typically, if I wanted to load information
about a customer, I might have something like:

1) Find Customer ID based on Emailaddress
2) Load customer object

In your webservice, you may think of implementing both of these methods, but
then for the consummer to load a customer in this fashion takes 2 round
trips to the webservice. It would work, but to reduce the round trips, I
would construct one webmethod that would load a customer based on email
address:

public CustomerClass GetCustomerFromEmail(string emailadress);
public CustomerClass GetCustomerFromID(string custid);

I realize this is a simplistic version, but hope you get the idea.
I guess maybe that's just good API design to begin with though.

Steve


"Bert Vandenberghe" <en*********@hotmail.com> wrote in message
news:eo**************@TK2MSFTNGP09.phx.gbl...
Hi,

I was wondering if there are any best practices on the creation of
webmethods? I'll try to explain this a little more:
My problem is that we are changing an existing (large) DCOM application to
use web services, but we have like hundreds of different methods you can
call and what I wanted to do, is add a couple of generic webmethods that
take a serializable .NET class or structure, and in that class or structure we put all the necessary information about the action that must be
performed. I would think this is a lot easier instead of adding all the
different methods, but my question is, if that is recommended to implement
this in such a way? If not, is it then recommended to add one service with
all these method, or is it better to split it up in different services? Is
there a recommended maximum of webmethods for one service?

I have to add that the web service will only be used internally, I mean that normally no other company will use our web service (we create the client
application).

Any thought or suggestions are welcome.

Thanks,
Bert

Nov 23 '05 #10
Hi Steve,

I get your point and you are absolutely correct, thanks for that advice.

But just to go a little deeper into this:
Imagine that it is possible to get a customer not only by email and ID, but
also by 20 other things. Then I see two options, you can add 22 webmethods,
but you could also add 1 webmethod with 2 arguments, first an enum to
specify on which field you are selecting the customer, and secondly the
string with the email, ID or one of the 20 other fields:
public CustomerClass GetCustomerFromEmail(string emailadress);
public CustomerClass GetCustomerFromID(string id);
public CustomerClass GetCustomerFromName(string name);
public CustomerClass GetCustomerFromAddress(string address);
public CustomerClass GetCustomerFromCountry(string country);
.... 22 of these methods ...

OR

public CustomerClass GetCustomer(enum field, string field);

Now, which one is preferable?
Then you could also take this a little further:
Imagine a webservice where you can not only retrieve customers, but also 20
other objects (e.g.: products, users, locations, ...). Then you can ask
yourself, if you have to add 21 webmethods, or just one webmethod with an
extra argument (= enum).
Thanks for your comments,
Bert
"Steve Lutz" <sl***@nospam.comcast.net> wrote in message
news:u9**************@TK2MSFTNGP09.phx.gbl...
Bert,

One thing I try to design in my webservices is to reduce the need for round trips to the webservice. So I attempt to rework some of my back-end methods to reduce this. For example, typically, if I wanted to load information
about a customer, I might have something like:

1) Find Customer ID based on Emailaddress
2) Load customer object

In your webservice, you may think of implementing both of these methods, but then for the consummer to load a customer in this fashion takes 2 round
trips to the webservice. It would work, but to reduce the round trips, I
would construct one webmethod that would load a customer based on email
address:

public CustomerClass GetCustomerFromEmail(string emailadress);
public CustomerClass GetCustomerFromID(string custid);

I realize this is a simplistic version, but hope you get the idea.
I guess maybe that's just good API design to begin with though.

Steve


"Bert Vandenberghe" <en*********@hotmail.com> wrote in message
news:eo**************@TK2MSFTNGP09.phx.gbl...
Hi,

I was wondering if there are any best practices on the creation of
webmethods? I'll try to explain this a little more:
My problem is that we are changing an existing (large) DCOM application to use web services, but we have like hundreds of different methods you can
call and what I wanted to do, is add a couple of generic webmethods that
take a serializable .NET class or structure, and in that class or

structure
we put all the necessary information about the action that must be
performed. I would think this is a lot easier instead of adding all the
different methods, but my question is, if that is recommended to implement this in such a way? If not, is it then recommended to add one service with all these method, or is it better to split it up in different services? Is there a recommended maximum of webmethods for one service?

I have to add that the web service will only be used internally, I mean

that
normally no other company will use our web service (we create the client
application).

Any thought or suggestions are welcome.

Thanks,
Bert



Nov 23 '05 #11
> Is using soap over tcp faster than over http? Otherwise it is indeed
better that we install WSE2.0 and that we use tcp instead of http.
Thanks for the tip.
Yes, the performance should be a little better. I have no concrete performance
testing numbers to point you at, but it's pretty obvious that every messag
sent will be lighter on the wire the HTTP headers. Plus you don't have to
parse those headers each time, no keep-alive management, the web server doesn't
need to route the messag to the right application, etc.
And I think it is indeed more fexible to use web services, just in
case a customer wants to expose it on the internet, you never know...


I agree.

Cheers,
Dre

Nov 23 '05 #12
Hi Bert:
public CustomerClass GetCustomerFromEmail(string emailadress);
public CustomerClass GetCustomerFromID(string id);
public CustomerClass GetCustomerFromName(string name);
public CustomerClass GetCustomerFromAddress(string address);
public CustomerClass GetCustomerFromCountry(string country);
... 22 of these methods ...

OR

public CustomerClass GetCustomer(enum field, string field);

Now, which one is preferable?


What Steve meant was make your web methods chunky and not chatty! What he
means is that if an atomic business operation can be implemented in a single
web method, do it. Do not split it into more granular web methods. Ofcourse,
you could use private helper methods at the web service side as they don't
involve to-n-fro client communication.

Your above is something different - it illustrates the difference two
interfaces (in the first one the type of the parameter is evident by the
method name while in the second one the type in encoded as another parameter
(enum). You should go with the first. It won't affect your performance at
all as you will be calling _only one (any)_ to get hold of a customer.

Thanks,
Mujtaba.
Nov 23 '05 #13
Hi Mujtaba,

Sorry if I did not make myself very clear, but I understood what Steve
meant, and what you are explaining here again, thanks for that.

But I was just getting back to my initial post with the example of
GetCustomerFromEmail and not going deeper into Steve's post as put in my
post, my mistake, sorry.

Anyway, I have to tell that I was a little suprised with your answer to the
different approches of the interfaces. You seem to choose for the 22
different webmethods instead of one single webmethod, what I think is much
simpler.

Thanks,

Bert


What Steve meant was make your web methods chunky and not chatty! What he
means is that if an atomic business operation can be implemented in a single web method, do it. Do not split it into more granular web methods. Ofcourse, you could use private helper methods at the web service side as they don't
involve to-n-fro client communication.

Your above is something different - it illustrates the difference two
interfaces (in the first one the type of the parameter is evident by the
method name while in the second one the type in encoded as another parameter (enum). You should go with the first. It won't affect your performance at
all as you will be calling _only one (any)_ to get hold of a customer.

Thanks,
Mujtaba.


Nov 23 '05 #14
Hi Bert:
Anyway, I have to tell that I was a little suprised with your answer to
the
different approches of the interfaces. You seem to choose for the 22
different webmethods instead of one single webmethod, what I think is much
simpler.


Using a single method is just easy to develop (atleast it looks easy to
develop). Using the 22 method option is more inline with OO practices and
cleaner.

Thanks,
Mujtaba.

Nov 23 '05 #15

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: mdh | last post by:
I have an application written for mod_perl and Apache that needs to be able to send some XML queries to a WebMethods server for access to corporate systems. I have been attempting to use LWP to...
2
by: byrocat | last post by:
I'm chasing after a documetn that was available on one of the Microsoft websites that was titled somethign like "MS SQL Server Best Practices" and detailed a nyumber of best practices about...
136
by: Matt Kruse | last post by:
http://www.JavascriptToolbox.com/bestpractices/ I started writing this up as a guide for some people who were looking for general tips on how to do things the 'right way' with Javascript. Their...
13
by: john doe | last post by:
A quick question, about so-called 'best practices', I'm interested in which of A/B of the two examples people would choose, and why. public enum MyEnum { Option1 = 0, Option2 = 1, Option3 =...
10
by: jojobar | last post by:
Hello, I am trying to use vs.net 2005 to migrate a project originally in vs.net 2003. I started with creation of a "web site", and then created folders for each component of the site. I read...
3
by: John Dalberg | last post by:
I am looking for an ASP.NET application on CodePlex which exemplifies best practices for the following: - Use of interfaces - Seperation of the UI, business and data tiers - Data Tier that uses...
6
dennison
by: dennison | last post by:
I am trying to write code for a class that has a couple of attributes that will can only be known upon creation. Because I think accessor functions (e.g. getSomething()) are outdate, I declared my...
2
by: sabbadin12 | last post by:
Hi, I'm going to work on an application that uses a postgreSQL database so that it can uses SQLServer 2005. I think I solved most problems on the programming side, but I still have some doubts...
4
by: trullock | last post by:
Hi, Can anyone suggest the best way to go about the following... I'm tracking clicks (mouse down x,y coordinates) on a web page by using some javascript to create an XHR which sends the...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.