Hi
Just asking for ideas on table design.
The design I have is as follows:
*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"
*tblRegistratio nData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"
*tblWarrantyDat a*
WarrantyID (PK)
RegID (FK) from tblRegistration Data
ClaimDate
"
"
tblBuildData details everything about the machine when it comes out of the
factory and the tblRegistration Data details when the machine was registered
after the customer buys it so the reason why the 1 -1 relationship. Warranty
claims can only be made against machines that have been registered is
another reason why the registration details are separate from the other
machine data.
This design is now starting to kick me in the butt where I really notice it
now when my client wanted to be able to enter a claim against a machine if
it's unregistered if certain criteria was met. This wasn't foreseen a couple
of years ago was the system was designed. I got around this problem with
code by inserting a date in the RegDate field and then deleting the date so
the AutoNumber was created for the tblWarrantyData could then create a
record.
How would you have designed the tables?
I'll like to move all the fields from the tblRegistration Data to the
tblBuildData to simplify the design and improve reporting but that will be a
major with modifying all objects in the database and SQL in code that use
that table structure. About 350 objects.
Stewart
8  2101 
"Stewart Allen" <sa****@NOT.wav e.THIS.co.nz> wrote in message
news:c8******** **@news.wave.co .nz... Hi
Just asking for ideas on table design.
The design I have is as follows:
*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"
*tblRegistratio nData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"
*tblWarrantyDat a*
WarrantyID (PK)
RegID (FK) from tblRegistration Data
ClaimDate
"
"
How would you have designed the tables?
Probably with a single table.
I'll like to move all the fields from the tblRegistration Data to the
tblBuildData to simplify the design and improve reporting but that will be
a major with modifying all objects in the database and SQL in code that use
that table structure. About 350 objects.
One option is to move add the extra columns to tblBuildData, delete
tblRegistration Data then create a query called tblRegistration Data using
tblBuildData. That way your existing code would not break until you have the
time to go through and replace all references to the query.
Hi Stewart,
If tblRegistration is truly 1-1 with tblBuild then get rid of field RegID
after you remove referential integrity. As always, make a backup of your
whole application before you start making changes. With the fields you
currently have it, tblRegistration looks like a junction table. A junction
table makes sense in a many to many situation. As you have explained things
it's a logical part of tblBuild.
If you make any changes to the schema there are likely to be changes
propogating throughout your application. However it shouldn't be too bad if
the back end is in Access. In this case, I'd be surprised if you're making
any meaningful use of RegID.
Are you aware that there are several that focus on specific parts of Access,
as well as this and another all-purpose Access newsgroup,
Microsoft.publi c.access.*
HTH
--
-Larry-
--
"Stewart Allen" <sa****@NOT.wav e.THIS.co.nz> wrote in message
news:c8******** **@news.wave.co .nz... Hi
Just asking for ideas on table design.
The design I have is as follows:
*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"
*tblRegistratio nData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"
*tblWarrantyDat a*
WarrantyID (PK)
RegID (FK) from tblRegistration Data
ClaimDate
"
"
tblBuildData details everything about the machine when it comes out of the
factory and the tblRegistration Data details when the machine was
registered after the customer buys it so the reason why the 1 -1 relationship.
Warranty claims can only be made against machines that have been registered is
another reason why the registration details are separate from the other
machine data.
This design is now starting to kick me in the butt where I really notice
it now when my client wanted to be able to enter a claim against a machine if
it's unregistered if certain criteria was met. This wasn't foreseen a
couple of years ago was the system was designed. I got around this problem with
code by inserting a date in the RegDate field and then deleting the date
so the AutoNumber was created for the tblWarrantyData could then create a
record.
How would you have designed the tables?
I'll like to move all the fields from the tblRegistration Data to the
tblBuildData to simplify the design and improve reporting but that will be
a major with modifying all objects in the database and SQL in code that use
that table structure. About 350 objects.
Stewart
Hi John,
A single table is also what I was thinking about. Creating new fields in the
tblBuild, deleting the tblRegistration and creating a query sounds good.
Stewart
"John Winterbottom" <as******@hotma il.com> wrote in message
news:2g******** ****@uni-berlin.de... "Stewart Allen" <sa****@NOT.wav e.THIS.co.nz> wrote in message
news:c8******** **@news.wave.co .nz... Hi
Just asking for ideas on table design.
The design I have is as follows:
*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"
*tblRegistratio nData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"
*tblWarrantyDat a*
WarrantyID (PK)
RegID (FK) from tblRegistration Data
ClaimDate
"
"
How would you have designed the tables?
Probably with a single table.
I'll like to move all the fields from the tblRegistration Data to the
tblBuildData to simplify the design and improve reporting but that will
be a major with modifying all objects in the database and SQL in code that
use that table structure. About 350 objects.
One option is to move add the extra columns to tblBuildData, delete
tblRegistration Data then create a query called tblRegistration Data using
tblBuildData. That way your existing code would not break until you have
the time to go through and replace all references to the query.
Hi Larry,
I intend to move all the fields from tblRegistration into tblBuild and then
recreate all the queries and SQL in code. The back end is
Access which makes the process easier.
What I might do is to start making the changes in my own time with my copy
of the front end and a test copy of the back end. When everything is working
correctly, back up their copy of the data, add the fields and change the
relationships and then run a couple of update queries then give them the new
copy of the front end.
Stewart
"Larry Daugherty" <La************ ********@verizo n.net> wrote in message
news:1B******** ***********@nwr ddc02.gnilink.n et... Hi Stewart,
If tblRegistration is truly 1-1 with tblBuild then get rid of field RegID
after you remove referential integrity. As always, make a backup of your
whole application before you start making changes. With the fields you
currently have it, tblRegistration looks like a junction table. A
junction table makes sense in a many to many situation. As you have explained
things it's a logical part of tblBuild.
If you make any changes to the schema there are likely to be changes
propogating throughout your application. However it shouldn't be too bad
if the back end is in Access. In this case, I'd be surprised if you're
making any meaningful use of RegID.
Are you aware that there are several that focus on specific parts of
Access, as well as this and another all-purpose Access newsgroup,
Microsoft.publi c.access.*
HTH
--
-Larry-
--
"Stewart Allen" <sa****@NOT.wav e.THIS.co.nz> wrote in message
news:c8******** **@news.wave.co .nz... Hi
Just asking for ideas on table design.
The design I have is as follows:
*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"
*tblRegistratio nData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"
*tblWarrantyDat a*
WarrantyID (PK)
RegID (FK) from tblRegistration Data
ClaimDate
"
"
tblBuildData details everything about the machine when it comes out of
the factory and the tblRegistration Data details when the machine was registered after the customer buys it so the reason why the 1 -1 relationship.
Warranty claims can only be made against machines that have been registered is
another reason why the registration details are separate from the other
machine data.
This design is now starting to kick me in the butt where I really notice
it now when my client wanted to be able to enter a claim against a machine
if it's unregistered if certain criteria was met. This wasn't foreseen a
couple of years ago was the system was designed. I got around this problem with
code by inserting a date in the RegDate field and then deleting the date
so the AutoNumber was created for the tblWarrantyData could then create a
record.
How would you have designed the tables?
I'll like to move all the fields from the tblRegistration Data to the
tblBuildData to simplify the design and improve reporting but that will
be a major with modifying all objects in the database and SQL in code that
use that table structure. About 350 objects.
Stewart
Stewart,
Your planned approach is sound development practice except for the bit about
"on your time". Your company/client will be the beneficiary of the changes
you make. Why shouldn't company/client pay for the changes?
HTH
--
-Larry-
--
"Stewart Allen" <sa****@NOT.wav e.THIS.co.nz> wrote in message
news:c8******** **@news.wave.co .nz... Hi Larry,
I intend to move all the fields from tblRegistration into tblBuild and
then recreate all the queries and SQL in code. The back end is
Access which makes the process easier.
What I might do is to start making the changes in my own time with my copy
of the front end and a test copy of the back end. When everything is
working correctly, back up their copy of the data, add the fields and change the
relationships and then run a couple of update queries then give them the
new copy of the front end.
Stewart
"Larry Daugherty" <La************ ********@verizo n.net> wrote in message
news:1B******** ***********@nwr ddc02.gnilink.n et... Hi Stewart,
If tblRegistration is truly 1-1 with tblBuild then get rid of field
RegID after you remove referential integrity. As always, make a backup of
your whole application before you start making changes. With the fields you
currently have it, tblRegistration looks like a junction table. A junction table makes sense in a many to many situation. As you have explained
things it's a logical part of tblBuild.
If you make any changes to the schema there are likely to be changes
propogating throughout your application. However it shouldn't be too
bad if the back end is in Access. In this case, I'd be surprised if you're making any meaningful use of RegID.
Are you aware that there are several that focus on specific parts of
Access, as well as this and another all-purpose Access newsgroup,
Microsoft.publi c.access.*
HTH
--
-Larry-
--
"Stewart Allen" <sa****@NOT.wav e.THIS.co.nz> wrote in message
news:c8******** **@news.wave.co .nz... Hi
Just asking for ideas on table design.
The design I have is as follows:
*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"
*tblRegistratio nData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"
*tblWarrantyDat a*
WarrantyID (PK)
RegID (FK) from tblRegistration Data
ClaimDate
"
"
tblBuildData details everything about the machine when it comes out of
the factory and the tblRegistration Data details when the machine was
registered after the customer buys it so the reason why the 1 -1 relationship.
Warranty claims can only be made against machines that have been registered is
another reason why the registration details are separate from the
other machine data.
This design is now starting to kick me in the butt where I really
notice it now when my client wanted to be able to enter a claim against a
machine if it's unregistered if certain criteria was met. This wasn't foreseen a couple of years ago was the system was designed. I got around this problem
with code by inserting a date in the RegDate field and then deleting the
date so the AutoNumber was created for the tblWarrantyData could then create a
record.
How would you have designed the tables?
I'll like to move all the fields from the tblRegistration Data to the
tblBuildData to simplify the design and improve reporting but that
will be a major with modifying all objects in the database and SQL in code that
use that table structure. About 350 objects.
Stewart
I intended to mention about 2 emails back that there are some tools out
there that can be very helpful in making changes: Speed Ferret, a
commercial product and Find And Replace, a shareware product from Rick
Fisher. You can download Find And Replace from www.rickworld.com
--
-Larry-
--
"Stewart Allen" <sa****@NOT.wav e.THIS.co.nz> wrote in message
news:c8******** **@news.wave.co .nz... Hi Larry,
I intend to move all the fields from tblRegistration into tblBuild and
then recreate all the queries and SQL in code. The back end is
Access which makes the process easier.
What I might do is to start making the changes in my own time with my copy
of the front end and a test copy of the back end. When everything is
working correctly, back up their copy of the data, add the fields and change the
relationships and then run a couple of update queries then give them the
new copy of the front end.
Stewart
"Larry Daugherty" <La************ ********@verizo n.net> wrote in message
news:1B******** ***********@nwr ddc02.gnilink.n et... Hi Stewart,
If tblRegistration is truly 1-1 with tblBuild then get rid of field
RegID after you remove referential integrity. As always, make a backup of
your whole application before you start making changes. With the fields you
currently have it, tblRegistration looks like a junction table. A junction table makes sense in a many to many situation. As you have explained
things it's a logical part of tblBuild.
If you make any changes to the schema there are likely to be changes
propogating throughout your application. However it shouldn't be too
bad if the back end is in Access. In this case, I'd be surprised if you're making any meaningful use of RegID.
Are you aware that there are several that focus on specific parts of
Access, as well as this and another all-purpose Access newsgroup,
Microsoft.publi c.access.*
HTH
--
-Larry-
--
"Stewart Allen" <sa****@NOT.wav e.THIS.co.nz> wrote in message
news:c8******** **@news.wave.co .nz... Hi
Just asking for ideas on table design.
The design I have is as follows:
*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"
*tblRegistratio nData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"
*tblWarrantyDat a*
WarrantyID (PK)
RegID (FK) from tblRegistration Data
ClaimDate
"
"
tblBuildData details everything about the machine when it comes out of
the factory and the tblRegistration Data details when the machine was
registered after the customer buys it so the reason why the 1 -1 relationship.
Warranty claims can only be made against machines that have been registered is
another reason why the registration details are separate from the
other machine data.
This design is now starting to kick me in the butt where I really
notice it now when my client wanted to be able to enter a claim against a
machine if it's unregistered if certain criteria was met. This wasn't foreseen a couple of years ago was the system was designed. I got around this problem
with code by inserting a date in the RegDate field and then deleting the
date so the AutoNumber was created for the tblWarrantyData could then create a
record.
How would you have designed the tables?
I'll like to move all the fields from the tblRegistration Data to the
tblBuildData to simplify the design and improve reporting but that
will be a major with modifying all objects in the database and SQL in code that
use that table structure. About 350 objects.
Stewart
I'll still plan charge them. What I mean by in my own time is that since I
have a copy of the front and back ends, I can do it in my own time if my
client wants the changes instead of travelling to their premises. I have no
intention to do this much work and not get paid for it.
Stewart
"Larry Daugherty" <La************ ********@verizo n.net> wrote in message
news:dZ******** ***********@nwr ddc02.gnilink.n et... Stewart,
Your planned approach is sound development practice except for the bit
about "on your time". Your company/client will be the beneficiary of the
changes you make. Why shouldn't company/client pay for the changes?
HTH
--
-Larry-
--
"Stewart Allen" <sa****@NOT.wav e.THIS.co.nz> wrote in message
news:c8******** **@news.wave.co .nz... Hi Larry,
I intend to move all the fields from tblRegistration into tblBuild and
then recreate all the queries and SQL in code. The back end is
Access which makes the process easier.
What I might do is to start making the changes in my own time with my
copy of the front end and a test copy of the back end. When everything is
working correctly, back up their copy of the data, add the fields and change the
relationships and then run a couple of update queries then give them the
new copy of the front end.
Stewart
"Larry Daugherty" <La************ ********@verizo n.net> wrote in message
news:1B******** ***********@nwr ddc02.gnilink.n et... Hi Stewart,
If tblRegistration is truly 1-1 with tblBuild then get rid of field RegID after you remove referential integrity. As always, make a backup of your whole application before you start making changes. With the fields
you currently have it, tblRegistration looks like a junction table. A
junction table makes sense in a many to many situation. As you have explained
things it's a logical part of tblBuild.
If you make any changes to the schema there are likely to be changes
propogating throughout your application. However it shouldn't be too bad if the back end is in Access. In this case, I'd be surprised if you're
making any meaningful use of RegID.
Are you aware that there are several that focus on specific parts of
Access, as well as this and another all-purpose Access newsgroup,
Microsoft.publi c.access.*
HTH
--
-Larry-
--
"Stewart Allen" <sa****@NOT.wav e.THIS.co.nz> wrote in message
news:c8******** **@news.wave.co .nz...
> Hi
>
> Just asking for ideas on table design.
>
> The design I have is as follows:
>
> *tblBuildData*
> BuildID (PK) AutoNumber
> ManufactureDate
> SerialNumber
> "
> "
>
> *tblRegistratio nData*
> BuildID (PK) 1 - 1 from tblBuildData
> RegID AutoNumber
> RegDate
> CustomerID
> "
> "
>
> *tblWarrantyDat a*
> WarrantyID (PK)
> RegID (FK) from tblRegistration Data
> ClaimDate
> "
> "
>
> tblBuildData details everything about the machine when it comes out
of the > factory and the tblRegistration Data details when the machine was
registered
> after the customer buys it so the reason why the 1 -1 relationship.
Warranty
> claims can only be made against machines that have been registered
is > another reason why the registration details are separate from the
other > machine data.
>
> This design is now starting to kick me in the butt where I really notice it
> now when my client wanted to be able to enter a claim against a machine if > it's unregistered if certain criteria was met. This wasn't foreseen
a couple
> of years ago was the system was designed. I got around this problem
with > code by inserting a date in the RegDate field and then deleting the date so
> the AutoNumber was created for the tblWarrantyData could then create
a > record.
>
> How would you have designed the tables?
>
> I'll like to move all the fields from the tblRegistration Data to the
> tblBuildData to simplify the design and improve reporting but that
will be a
> major with modifying all objects in the database and SQL in code
that use > that table structure. About 350 objects.
>
> Stewart
>
>
Good idea. It would speed up the changes.
Stewart
"Larry Daugherty" <La************ ********@verizo n.net> wrote in message
news:S1******** ************@nw rddc02.gnilink. net... I intended to mention about 2 emails back that there are some tools out
there that can be very helpful in making changes: Speed Ferret, a
commercial product and Find And Replace, a shareware product from Rick
Fisher. You can download Find And Replace from www.rickworld.com
--
-Larry-
--
"Stewart Allen" <sa****@NOT.wav e.THIS.co.nz> wrote in message
news:c8******** **@news.wave.co .nz... Hi Larry,
I intend to move all the fields from tblRegistration into tblBuild and
then recreate all the queries and SQL in code. The back end is
Access which makes the process easier.
What I might do is to start making the changes in my own time with my
copy of the front end and a test copy of the back end. When everything is
working correctly, back up their copy of the data, add the fields and change the
relationships and then run a couple of update queries then give them the
new copy of the front end.
Stewart
"Larry Daugherty" <La************ ********@verizo n.net> wrote in message
news:1B******** ***********@nwr ddc02.gnilink.n et... Hi Stewart,
If tblRegistration is truly 1-1 with tblBuild then get rid of field RegID after you remove referential integrity. As always, make a backup of your whole application before you start making changes. With the fields
you currently have it, tblRegistration looks like a junction table. A
junction table makes sense in a many to many situation. As you have explained
things it's a logical part of tblBuild.
If you make any changes to the schema there are likely to be changes
propogating throughout your application. However it shouldn't be too bad if the back end is in Access. In this case, I'd be surprised if you're
making any meaningful use of RegID.
Are you aware that there are several that focus on specific parts of
Access, as well as this and another all-purpose Access newsgroup,
Microsoft.publi c.access.*
HTH
--
-Larry-
--
"Stewart Allen" <sa****@NOT.wav e.THIS.co.nz> wrote in message
news:c8******** **@news.wave.co .nz...
> Hi
>
> Just asking for ideas on table design.
>
> The design I have is as follows:
>
> *tblBuildData*
> BuildID (PK) AutoNumber
> ManufactureDate
> SerialNumber
> "
> "
>
> *tblRegistratio nData*
> BuildID (PK) 1 - 1 from tblBuildData
> RegID AutoNumber
> RegDate
> CustomerID
> "
> "
>
> *tblWarrantyDat a*
> WarrantyID (PK)
> RegID (FK) from tblRegistration Data
> ClaimDate
> "
> "
>
> tblBuildData details everything about the machine when it comes out
of the > factory and the tblRegistration Data details when the machine was
registered
> after the customer buys it so the reason why the 1 -1 relationship.
Warranty
> claims can only be made against machines that have been registered
is > another reason why the registration details are separate from the
other > machine data.
>
> This design is now starting to kick me in the butt where I really notice it
> now when my client wanted to be able to enter a claim against a machine if > it's unregistered if certain criteria was met. This wasn't foreseen
a couple
> of years ago was the system was designed. I got around this problem
with > code by inserting a date in the RegDate field and then deleting the date so
> the AutoNumber was created for the tblWarrantyData could then create
a > record.
>
> How would you have designed the tables?
>
> I'll like to move all the fields from the tblRegistration Data to the
> tblBuildData to simplify the design and improve reporting but that
will be a
> major with modifying all objects in the database and SQL in code
that use > that table structure. About 350 objects.
>
> Stewart
>
>
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Michael Lauzon |
last post by:
This is not for a class, I have a group on SourceForge, this is what
one of the Developers is asking; the more advanced you can make it
right off all the better!:
Can someone please create some MySQL to create the first table: the
players table.
It will need to include (as a minimum):
- ID (unique)
|
by: Neal |
last post by:
Patrick Griffiths weighs in on the CSS vs table layout debate in his blog
entry "Tables my ass" - http://www.htmldog.com/ptg/archives/000049.php . A
quite good article.
|
by: 2trax |
last post by:
Hi all,
I am trying to mimic the unix security model (users and groups) in a web
app.
I have thought of two ways of implementing this, but am unsure which would
be better. The first design utilises three tables, while the second
utilises two tables, however one of the columns in the first table is an
an array.
|
by: kimi |
last post by:
I have just started working on a project that is partially complete. It
is an application that is using access to store test results. The test
results are being stored in two Access 2000 databases.
DB #1 = StudentDB
DB #2 = TestResulstsDB
Why are there 2 dbs? I do not know - but that is one of the tings that
we will be changing. Combining all of the data into one database.
|
by: MLH |
last post by:
If I open an A97 table, resort its key-field to descending order and
attempt to close the table, A97 asks me if I wish to save the table
DESIGN? Now really, I don't think the table design is being saved
at all. If so, how does one explain these facts:
1) say I do click Yes to save the table design
2) later I open the table manually and, sure enough, key field is
shown in descending order
3) I run this in debug window... ?DLookup("",...
| | |
by: Nathan Sokalski |
last post by:
When editing an ASP Table, Visual Studio does not allow me to edit it in
Design View. This makes it harder to add elements, because I must add every
element either by using Design View to create the element outside of the
table and then using cut & paste in HTML View to move it to the desired
location, or by manually typing the code in using HTML View. The first
technique sometimes does not automatically update the list of elements...
|
by: david |
last post by:
I have asked this question before. But it does not work for me. Given radion
buttons in the web form design page. What I did is described as follows.
A panel control is dragged into the design form, and a table control is
dragged into the panel from tooolbox. Add cells for the table through the
properties. Now I cut a radio button, and click the table (note I can not
select a cell), then right click Paste. The button is not in expected...
|
by: phil-news-nospam |
last post by:
Is there really any advantage to using DIV elements with float style
properies, vs. the old method of TABLE and TR and TD?
I'm finding that by using DIV, it still involves the same number of
elements in the HTML to get everything just right. When you consider
the class attribute on the DIV elements, there's not much size savings
anymore for using DIV.
There are other disadvantages to not using TABLE/TR/TD, such as the
lack of ability...
|
by: yanjie.ma |
last post by:
Hi,
I've got a two part question on table and form design (sorry for the
length but it takes a bit to explain). Our sales department uses a
look-up table to help the them select the best equipment to use for a
customer's needs. It basically consists of a table with the following
setup:
Equipment: Option1: Option2: Option3: Option 4: ...
-------- ------- ------- -------- --------
|
by: csolomon |
last post by:
Hello:
I was wondering if I could get some input on how to address a design
issue, involving my composite table.
I have one portion of my project complete. The following forms and
reports I will add, piggyback off of my existing design.
The part I have already completed allows my users to create a design
sample; this is made up of several materials to create one sample. I
have accomplished this using this design:
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
| | |
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 synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
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 captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
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 most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
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 instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
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 into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
| | |
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
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
| |
