473,545 Members | 2,135 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Relationships. Does anyone use them?

I'm curious about your opinion on setting relationships.

When I designed my first app in Access I'd go to Tools/Relationships and
set the relationships. Over time I'd go into the window and see
relationship spaghetti....ta bles/queries all overthe place with lots of
relationship lines between here and there.

After that first app I didn't do relationships. If I had a query, I
defined the relationship. Many of the times when I create a new query
and add 2 tables together it creates the correct relationship between
the two tables. I believe this is due to using a foreign key with the
same name. I cared not about cascading deletes or cascading updates or
the type of relationship so the relationships window is clean of tables.

And if I need to, I'll create a query on the fly via code. Again, I set
the relationships. I know these queries aren't compiled for optimacy
like a querydef but operate well.

My apps don't appear to suffer from no relationships. Speeds very
acceptable, the results the same. So is setting relationships just more
overhead in creating an app and unnecessary...o r do you believe the app
should have all relationships defined?


Apr 28 '06 #1
45 3353
salad <oi*@vinegar.co m> wrote in news:Sow4g.7230 $BS2.6977
@newsread1.news .pas.earthlink. net:
I'm curious about your opinion on setting relationships.

When I designed my first app in Access I'd go to Tools/Relationships and
set the relationships. Over time I'd go into the window and see
relationship spaghetti....ta bles/queries all overthe place with lots of
relationship lines between here and there.

After that first app I didn't do relationships. If I had a query, I
defined the relationship. Many of the times when I create a new query
and add 2 tables together it creates the correct relationship between
the two tables. I believe this is due to using a foreign key with the
same name. I cared not about cascading deletes or cascading updates or
the type of relationship so the relationships window is clean of tables.

And if I need to, I'll create a query on the fly via code. Again, I set
the relationships. I know these queries aren't compiled for optimacy
like a querydef but operate well.

My apps don't appear to suffer from no relationships. Speeds very
acceptable, the results the same. So is setting relationships just more
overhead in creating an app and unnecessary...o r do you believe the app
should have all relationships defined?


Relationships are the Database! There is nothing else to say.

This is not a matter of opinion and it is not an item for debate.

--
Lyle Fairfield
Apr 28 '06 #2

salad wrote:
I'm curious about your opinion on setting relationships.


Well, unless you write SPs to enforce all your participation rules, I
would think *not* enforcing RI with relationships is a PITA. It's much
easier, IMO, to have Access do it for you.

Apr 28 '06 #3
salad wrote:
My apps don't appear to suffer from no relationships. Speeds very
acceptable, the results the same. So is setting relationships just
more overhead in creating an app and unnecessary...o r do you believe
the app should have all relationships defined?
Hi Salad,

One of the basic precepts of relational database design is to have the
data structure do as much for you as possible. Presumably you are
doing much of this already with your table design, ie, allowing nulls,
setting indexes with no repeats and myriad other tasks.

In other database systems, the terms for these sorts of things are
generally called constraints - I believe that is the term used in the
ANSI/SQL standards as well.

One important constraint is what in Oracle is called the foreign key
constraint - this is the equivalent of relationships in Jet.

It's nothing whatsoever to do with speed of queries or SQL statements.
They are to do with ensuring records are not orphaned. There are many
examples were you don't want orphaned records - think of a table of
purchase orders and a table of individual transactions that are all
linked to a purchase order. You don't want the any transactions
standing around without a purchase order - it makes no sense.

FK constraints/relationships are meant to address this sort of thing.
This is relational database 101. 8)

It's a very established concept in relational design that it's dangerous
to rely on constraints that are enforced by form design:
Many of the times when I create a new query and add 2 tables together
it creates the correct relationship between the two tables.
This is not a relationship. What you are describing is a join. It's
not a constraint or a relationship and it does not prevent deletion of
linked records that should not be deleted if you don't want orphaned
records.
I
believe this is due to using a foreign key with the same name.
No, this is a simple join. A foreign key has absolutely nothing
whatsoever to do with with what you are describing. The name of the
joined fields/cloumns is immaterial.
I
cared not about cascading deletes or cascading updates or the type of
relationship so the relationships window is clean of tables.
I think you've missed the point of what relationships are. See my
ruminating above! 8)
And if I need to, I'll create a query on the fly via code. Again, I
set the relationships. I know these queries aren't compiled for
optimacy like a querydef but operate well.
You are talking apples and oranges. I think you've mixed up what
queries, ie, select sql statements, and relationships are.

The purpose of relationship is *NOT*, repeat, *NOT* to make the
construction of queries easier!!! In the Access query builder design
window, they are used to help you as a bonus, but again, that is *NOT*
what the purpose of relationships, ie, foreign key constraints are.
My apps don't appear to suffer from no relationships. Speeds very
acceptable, the results the same.
Speed is not a benefit of relationships. Here, you seem to be confusing
indexes with relationships.
So is setting relationships just
more overhead in creating an app and unnecessary...o r do you believe
the app should have all relationships defined?


I know some here might jump on me for saying this, but an application
without foreign key constraints/relationships is not worth its weight in
electrons.

If you aren't having problems, then your applications are reasonably
small with respect to numbers of tables and records and the
"relationsh ip" between tables.

Salad, your knowledge of VBA and various coding techniques as
demonstrated by your responses given here are excellent and over the
past couple of years, many folks, including me, have benefited from your
posts. But given your question here, I think you really, really, really
need to read up on theory and practicality of relational database design
and structure.

I hope this was of some help. 8)

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Apr 29 '06 #4
TIMMY! wrote:
salad wrote:
My apps don't appear to suffer from no relationships. Speeds very
acceptable, the results the same. So is setting relationships just
more overhead in creating an app and unnecessary...o r do you believe
the app should have all relationships defined?

Hi Salad,

One of the basic precepts of relational database design is to have the
data structure do as much for you as possible. Presumably you are
doing much of this already with your table design, ie, allowing nulls,
setting indexes with no repeats and myriad other tasks.

In other database systems, the terms for these sorts of things are
generally called constraints - I believe that is the term used in the
ANSI/SQL standards as well.

One important constraint is what in Oracle is called the foreign key
constraint - this is the equivalent of relationships in Jet.

It's nothing whatsoever to do with speed of queries or SQL statements.
They are to do with ensuring records are not orphaned. There are many
examples were you don't want orphaned records - think of a table of
purchase orders and a table of individual transactions that are all
linked to a purchase order. You don't want the any transactions
standing around without a purchase order - it makes no sense.

FK constraints/relationships are meant to address this sort of thing.
This is relational database 101. 8)

It's a very established concept in relational design that it's dangerous
to rely on constraints that are enforced by form design:
Many of the times when I create a new query and add 2 tables together
it creates the correct relationship between the two tables.

This is not a relationship. What you are describing is a join. It's
not a constraint or a relationship and it does not prevent deletion of
linked records that should not be deleted if you don't want orphaned
records.
I
believe this is due to using a foreign key with the same name.

No, this is a simple join. A foreign key has absolutely nothing
whatsoever to do with with what you are describing. The name of the
joined fields/cloumns is immaterial.
> I

cared not about cascading deletes or cascading updates or the type of
relationship so the relationships window is clean of tables.

I think you've missed the point of what relationships are. See my
ruminating above! 8)
And if I need to, I'll create a query on the fly via code. Again, I
set the relationships. I know these queries aren't compiled for
optimacy like a querydef but operate well.

You are talking apples and oranges. I think you've mixed up what
queries, ie, select sql statements, and relationships are.

The purpose of relationship is *NOT*, repeat, *NOT* to make the
construction of queries easier!!! In the Access query builder design
window, they are used to help you as a bonus, but again, that is *NOT*
what the purpose of relationships, ie, foreign key constraints are.
My apps don't appear to suffer from no relationships. Speeds very
acceptable, the results the same.

Speed is not a benefit of relationships. Here, you seem to be confusing
indexes with relationships.
So is setting relationships just
more overhead in creating an app and unnecessary...o r do you believe
the app should have all relationships defined?

I know some here might jump on me for saying this, but an application
without foreign key constraints/relationships is not worth its weight in
electrons.

If you aren't having problems, then your applications are reasonably
small with respect to numbers of tables and records and the
"relationsh ip" between tables.

Salad, your knowledge of VBA and various coding techniques as
demonstrated by your responses given here are excellent and over the
past couple of years, many folks, including me, have benefited from your
posts. But given your question here, I think you really, really, really
need to read up on theory and practicality of relational database design
and structure.

I hope this was of some help. 8)

Yes. It sounds like you developers that responded to me spend a lot of
time in the Relationship window.

Not doing so is one task I don't think about...or want to think about.

If I have EmpId in Employees, and EmpID in table Orders, if I add those
2 tables in the QB, a relationship line is automatically drawn. If it
does that, why do I need to add 2 tables in the Relationship window and
set relationships? What do I care if I didn't go in into the
relationships window to set the relationship... .for the most part its
always done for me.

The spaghetti relationships graphically displayed in the Relationships
window from my first app turned me off from using the Relationship
window. I guess the graphical view of relationships is unnecessary for
me. It may be a necessity for others like you.

We may be talking apples and oranges. I'm glad I've helped you out in
the past.
Apr 29 '06 #5
Br
salad wrote:
TIMMY! wrote:
salad wrote:
My apps don't appear to suffer from no relationships. Speeds very
acceptable, the results the same. So is setting relationships just
more overhead in creating an app and unnecessary...o r do you believe
the app should have all relationships defined?

Hi Salad,

One of the basic precepts of relational database design is to have
the data structure do as much for you as possible. Presumably you
are doing much of this already with your table design, ie, allowing
nulls, setting indexes with no repeats and myriad other tasks.

In other database systems, the terms for these sorts of things are
generally called constraints - I believe that is the term used in the
ANSI/SQL standards as well.

One important constraint is what in Oracle is called the foreign key
constraint - this is the equivalent of relationships in Jet.

It's nothing whatsoever to do with speed of queries or SQL
statements. They are to do with ensuring records are not orphaned. There
are many examples were you don't want orphaned records - think
of a table of purchase orders and a table of individual transactions
that are all linked to a purchase order. You don't want the any
transactions standing around without a purchase order - it makes no
sense. FK constraints/relationships are meant to address this sort of
thing.
This is relational database 101. 8)

It's a very established concept in relational design that it's
dangerous to rely on constraints that are enforced by form design:
Many of the times when I create a new query and add 2 tables
together it creates the correct relationship between the two tables.

This is not a relationship. What you are describing is a join. It's
not a constraint or a relationship and it does not prevent deletion
of linked records that should not be deleted if you don't want
orphaned records.
I
believe this is due to using a foreign key with the same name.

No, this is a simple join. A foreign key has absolutely nothing
whatsoever to do with with what you are describing. The name of the
joined fields/cloumns is immaterial.
> I

cared not about cascading deletes or cascading updates or the type
of relationship so the relationships window is clean of tables.

I think you've missed the point of what relationships are. See my
ruminating above! 8)
And if I need to, I'll create a query on the fly via code. Again, I
set the relationships. I know these queries aren't compiled for
optimacy like a querydef but operate well.

You are talking apples and oranges. I think you've mixed up what
queries, ie, select sql statements, and relationships are.

The purpose of relationship is *NOT*, repeat, *NOT* to make the
construction of queries easier!!! In the Access query builder design
window, they are used to help you as a bonus, but again, that is
*NOT* what the purpose of relationships, ie, foreign key constraints
are.
My apps don't appear to suffer from no relationships. Speeds very
acceptable, the results the same.

Speed is not a benefit of relationships. Here, you seem to be
confusing indexes with relationships.
So is setting relationships just
more overhead in creating an app and unnecessary...o r do you believe
the app should have all relationships defined?

I know some here might jump on me for saying this, but an application
without foreign key constraints/relationships is not worth its
weight in electrons.

If you aren't having problems, then your applications are reasonably
small with respect to numbers of tables and records and the
"relationsh ip" between tables.

Salad, your knowledge of VBA and various coding techniques as
demonstrated by your responses given here are excellent and over the
past couple of years, many folks, including me, have benefited from
your posts. But given your question here, I think you really,
really, really need to read up on theory and practicality of
relational database design and structure.

I hope this was of some help. 8)

Yes. It sounds like you developers that responded to me spend a lot
of time in the Relationship window.

Not doing so is one task I don't think about...or want to think about.

If I have EmpId in Employees, and EmpID in table Orders, if I add
those 2 tables in the QB, a relationship line is automatically drawn.
If it does that, why do I need to add 2 tables in the Relationship
window and set relationships? What do I care if I didn't go in into
the relationships window to set the relationship... .for the most part
its always done for me.


It was just explained to you:)

What you experience is an automatic join in the Access query editor.

A relationship is an enforced link between to tables.
The spaghetti relationships graphically displayed in the Relationships
window from my first app turned me off from using the Relationship
window. I guess the graphical view of relationships is unnecessary
for me. It may be a necessity for others like you.
It's a bit of an art not crossing lines (or avoiding it).

Sounds like you've never done any formal database design? (E-R diagrams,
yada yada)
We may be talking apples and oranges. I'm glad I've helped you out in
the past.


If you notice in your query when you get an auto join it is just a line? If
you have relationships set correctly you will see the type of relationship
('many to one' usually).

It's a question of good design. Setting relationships is basic database
design.

I recommend if you are really interested in good design that you get a book
on database theory. A lot of it becomes automatic (eg. most of us normalise
our tables at least to some degree without thinking about it). It's like
maths. You may have some quirky way that seems to work ok, but it's much
better if you have a good foundation in the basic theory. If you're going to
be developing a decent size application I'd shudder at the thought of not
setting relationships between my tables. In fact I usually spend a good
amount of time just designing my tables/relationships to make sure they will
handle the requirements. Forms/etc are just nice interfaces for users.

*end rant* :)

regards,

Bradley
Apr 29 '06 #6
Br@dley wrote:
Yes. It sounds like you developers that responded to me spend a lot
of time in the Relationship window.

Not doing so is one task I don't think about...or want to think about.

If I have EmpId in Employees, and EmpID in table Orders, if I add
those 2 tables in the QB, a relationship line is automatically drawn.
If it does that, why do I need to add 2 tables in the Relationship
window and set relationships? What do I care if I didn't go in into
the relationships window to set the relationship... .for the most part
its always done for me.
It was just explained to you:)

What you experience is an automatic join in the Access query editor.

A relationship is an enforced link between to tables.

The spaghetti relationships graphically displayed in the Relationships
window from my first app turned me off from using the Relationship
window. I guess the graphical view of relationships is unnecessary
for me. It may be a necessity for others like you.

It's a bit of an art not crossing lines (or avoiding it).

Sounds like you've never done any formal database design? (E-R diagrams,
yada yada)


Nope. 20 years of designing database applications, nothing formal tho.
Left the tux at the cleaners, picked up swim trunks and Hawaiian
shirts instead.
We may be talking apples and oranges. I'm glad I've helped you out in
the past.

If you notice in your query when you get an auto join it is just a line? If
you have relationships set correctly you will see the type of relationship
('many to one' usually).


Yeah. I set it there in the QB, not in the relationship window. I have
no relationships in the Relationship window. My MsysRelationshi ps table
is empty. I figure someone at MS was smart enough to check keys in
tables and set the joins in the QB if possible. Not much else to it.

I've never had the problem of creating records in the many table and not
creating records in the ones table.

It's a question of good design. Setting relationships is basic database
design.

I recommend if you are really interested in good design that you get a book
on database theory. A lot of it becomes automatic (eg. most of us normalise
our tables at least to some degree without thinking about it). It's like
maths. You may have some quirky way that seems to work ok, but it's much
better if you have a good foundation in the basic theory. If you're going to
be developing a decent size application I'd shudder at the thought of not
setting relationships between my tables. In fact I usually spend a good
amount of time just designing my tables/relationships to make sure they will
handle the requirements. Forms/etc are just nice interfaces for users.

*end rant* :)
Why? So I can echo back Codds Rules to impress people? Yawn.

It's like a many-to-many relationship. I think I had one one once in an
application...b ack b4 PC database systems used SQL in the language.
I've seen no need to use one since.

It appears that the Relationship window is used by quite a few. I was
curious if it was. I guess I'm missing all the fun.

regards,

Bradley

Apr 29 '06 #7
Why would you even *consider* taking on the responsibility to ensure that
every table entry will still relate correctly to every other table, before
you allow any insert, delete, and append to take place, in any form, action
query, or recordset ... when the Access data engine can do all that for you?
That would increase the development time by at least one order of magnitude,
make maintaining the database a nightmare, and leave you still uncertain you
got absolutely everything covered.

The relationship diagram is a brilliant way to view the big picture of the
database. You can fit most of an average sized database on a printed A3
page. If the database is too large, Stephen Lebans lets you break it into
blocks so you can save and restore different views:
http://www.lebans.com/saverelationshipview.htm

I depend so heavily on engine-level integrity that I modified the
relationship report so I can see the field types, indexes, and the
properties that affect the relational integrity:
Relationship Report with extended field information
at:
http://allenbrowne.com/AppRelReport.html

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"salad" <oi*@vinegar.co m> wrote in message
news:So******** *********@newsr ead1.news.pas.e arthlink.net...
I'm curious about your opinion on setting relationships.

When I designed my first app in Access I'd go to Tools/Relationships and
set the relationships. Over time I'd go into the window and see
relationship spaghetti....ta bles/queries all overthe place with lots of
relationship lines between here and there.

After that first app I didn't do relationships. If I had a query, I
defined the relationship. Many of the times when I create a new query and
add 2 tables together it creates the correct relationship between the two
tables. I believe this is due to using a foreign key with the same name.
I cared not about cascading deletes or cascading updates or the type of
relationship so the relationships window is clean of tables.

And if I need to, I'll create a query on the fly via code. Again, I set
the relationships. I know these queries aren't compiled for optimacy like
a querydef but operate well.

My apps don't appear to suffer from no relationships. Speeds very
acceptable, the results the same. So is setting relationships just more
overhead in creating an app and unnecessary...o r do you believe the app
should have all relationships defined?

Apr 29 '06 #8
Br
salad wrote:
Br@dley wrote:
Yes. It sounds like you developers that responded to me spend a lot
of time in the Relationship window.

Not doing so is one task I don't think about...or want to think
about. If I have EmpId in Employees, and EmpID in table Orders, if I add
those 2 tables in the QB, a relationship line is automatically
drawn. If it does that, why do I need to add 2 tables in the
Relationship window and set relationships? What do I care if I
didn't go in into the relationships window to set the
relationship... .for the most part its always done for me.
It was just explained to you:)

What you experience is an automatic join in the Access query editor.

A relationship is an enforced link between to tables.

The spaghetti relationships graphically displayed in the
Relationships window from my first app turned me off from using the
Relationship window. I guess the graphical view of relationships
is unnecessary for me. It may be a necessity for others like you.

It's a bit of an art not crossing lines (or avoiding it).

Sounds like you've never done any formal database design? (E-R
diagrams, yada yada)


Nope. 20 years of designing database applications, nothing formal
tho. Left the tux at the cleaners, picked up swim trunks and Hawaiian
shirts instead.


What does "database design" mean to you?
We may be talking apples and oranges. I'm glad I've helped you out
in the past.

If you notice in your query when you get an auto join it is just a
line? If you have relationships set correctly you will see the type
of relationship ('many to one' usually). Yeah. I set it there in the QB, not in the relationship window. I
have no relationships in the Relationship window. My
MsysRelationshi ps table is empty. I figure someone at MS was smart
enough to check keys in tables and set the joins in the QB if
possible. Not much else to it.
As has been said before relationships are far more important than just
making it easy to join tables when creating queries.
I've never had the problem of creating records in the many table and
not creating records in the ones table.
What do you do when data is updated/deleted? What stops data being added to
a secondary table when there is none in the parent?
It's a question of good design. Setting relationships is basic
database design.

I recommend if you are really interested in good design that you get
a book on database theory. A lot of it becomes automatic (eg. most
of us normalise our tables at least to some degree without thinking
about it). It's like maths. You may have some quirky way that seems
to work ok, but it's much better if you have a good foundation in
the basic theory. If you're going to be developing a decent size
application I'd shudder at the thought of not setting relationships
between my tables. In fact I usually spend a good amount of time
just designing my tables/relationships to make sure they will handle
the requirements. Forms/etc are just nice interfaces for users. *end
rant* :)


Why? So I can echo back Codds Rules to impress people? Yawn.


We're talking about good design, not impressions.

It's perplexing that you say you develop database applications for 20 years
yet shun Codds Rules...?
It's like a many-to-many relationship. I think I had one one once in
an application...b ack b4 PC database systems used SQL in the language.
I've seen no need to use one since.
Doesn't mean they are not valid/useful/etc. I have used them a number of
times (obviously implemented as three tables and one-to-many).
It appears that the Relationship window is used by quite a few. I was
curious if it was. I guess I'm missing all the fun.


For me it's not about who uses the relationship window, rather how people
design their apps. IMO start with designing the data structures
(tables/relationship/indexes) and make sure they suit the requirements (ie.
design the database). It's the basic building block on which you build the
interface/etc.

Understanding Relational Database Design
http://www.support.microsoft.com/?scid=kb;EN-US;234208

--
regards,

Bradley
Apr 29 '06 #9
rkc
salad wrote:
I'm curious about your opinion on setting relationships.

When I designed my first app in Access I'd go to Tools/Relationships and
set the relationships. Over time I'd go into the window and see
relationship spaghetti....ta bles/queries all overthe place with lots of
relationship lines between here and there.

After that first app I didn't do relationships.


So you don't use the database engine to enforce referential
integrity because the gui tool provided by Access annoys you?

Now I am curious. Do you create unique indexes in tables that have
an autonumber as the primary key? How about using validation rules?
Field sizes? Allow zero length strings? Required?
Apr 29 '06 #10

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

Similar topics

2
4118
by: Max | last post by:
Hi. I really hope someone can help me. Going slowly insane with this problem. I have a two Access 2000 databases. One is the backend containing tables and some admin queries. The other is the front end with forms / queries and links to the tables in the back end. From the Relationships window I selected File / Print Relationships. The...
2
1897
by: Squirrel | last post by:
Hi everyone, I have an Access 2002 database, split into frontend and backend, both files on one PC for some initial test data entry. Data entry person is an intelligent college student with no Access experience. She wouldn't go thrashing around attempting to break things. The relationships have all disappeared and I now have a few orphan...
7
2115
by: davegb | last post by:
I'm totally new to relational database design. My boss has asked me to create a database of information on the employees in our group. Seemed to me like a simple application to learn the ropes. A couple of things are confusing me. The first is "Relationships" and "Joins". Are they different names for the same thing? If not, what is the...
10
6989
by: Dixie | last post by:
I need to delete some relationships in code. How do I know what the names of those relationships are?
13
2045
by: ARC | last post by:
Hello all, Prior to going live with my app, I have questions on relationships theory. My prior app was done in Access 97, and I did NOT use relationships at all. I have 65 tables in my back-end database, and with Access 97, if you added relationships, it would add multiple copies of the same relationships over and over, so I decided not...
4
4373
by: netnewbie78 | last post by:
Hello All, I don't have a problem (but maybe I will after I explain). I have a question with regards to something I saw in Access 2007. But first, a little backstory: I'm writing a very small stock database. For now, it will simply track what products come in (Stocks bought by Project) and what products go out (Stocks sold to by Project)...
0
7401
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 effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
0
7656
Oralloy
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, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
0
7808
jinu1996
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 tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
1
7423
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
7757
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
1
5329
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 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 a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
4945
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
1
1884
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
0
704
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

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.