473,688 Members | 3,186 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

SQL 2000 - Row Level Locking

Hi,

We have encountered deadlock on a table which is used to generate
sequential numbers for different categories eg typical entries

Category Value

TRADE_NO 1456
JOB_NO 267
.....

The applications reference the relevant category applicable to them
and update
the Value accordingly. This is table is very small, occupying 1 page.
However, it has no index as it was not seen to be appropriate for a
table this size.

However, can someone please advise whether

1. An index is required for row level locking
2. If an index on a table as small as above is likely to reduce the
deadlock rate.

Also, please consider the following but which I am not sure is
relevant for above query.

We noted that when we migrated the database concerned from SQL 6.5 to
SQL 2000, using DTS, that the database was NOT strictly in SQL 2000
format for non clustered indexes (NC) ie the clustered key was not
part of the NC index until the clustered index was rebuilt.

Given this should I just rebuild this table with a fake index and drop
it thereafter.

We are aware of the different techniques used to avoid deadlocks (eg
tables accessed in same order etc) and have , as much as possible,
implemented those practices.

I thank you in advance for any help you may be able to offer.

Thanks

Puvendran
Jul 20 '05 #1
12 9567
> 1. An index is required for row level locking

Yes. It's always a good idea for all tables to have a primary key
regardless of table size. Not only is this a best practice in database
design, SQL Server will create a unique index to support the primary key
constraint and this allows SQL Server to develop better execution plans for
joins and implement row-level locking.
2. If an index on a table as small as above is likely to reduce the
deadlock rate.
Yes but you can still have problems if you update different rows as part of
the same transaction and perform updates in different sequence. You might
consider using IDENTITY since this will improve concurrency.
We noted that when we migrated the database concerned from SQL 6.5 to
SQL 2000, using DTS, that the database was NOT strictly in SQL 2000
format for non clustered indexes (NC) ie the clustered key was not
part of the NC index until the clustered index was rebuilt.
I'm not sure what you mean here. In SQL 2000, the clustered index keys are
always stored in non-clustered index leaf pages. This is done automatically
by SQL Server so you don't need to do anything special to make this happen,
even if clustered index keys are not non-clustered index columns. SQL
Server uses the clustered index values from the non-clustered index for
bookmark lookups and to cover queries when appropriate.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Puvendran" <pu************ *******@btfinan cialgroup.com> wrote in message
news:d5******** *************** ***@posting.goo gle.com... Hi,

We have encountered deadlock on a table which is used to generate
sequential numbers for different categories eg typical entries

Category Value

TRADE_NO 1456
JOB_NO 267
....

The applications reference the relevant category applicable to them
and update
the Value accordingly. This is table is very small, occupying 1 page.
However, it has no index as it was not seen to be appropriate for a
table this size.

However, can someone please advise whether

1. An index is required for row level locking
2. If an index on a table as small as above is likely to reduce the
deadlock rate.

Also, please consider the following but which I am not sure is
relevant for above query.

We noted that when we migrated the database concerned from SQL 6.5 to
SQL 2000, using DTS, that the database was NOT strictly in SQL 2000
format for non clustered indexes (NC) ie the clustered key was not
part of the NC index until the clustered index was rebuilt.

Given this should I just rebuild this table with a fake index and drop
it thereafter.

We are aware of the different techniques used to avoid deadlocks (eg
tables accessed in same order etc) and have , as much as possible,
implemented those practices.

I thank you in advance for any help you may be able to offer.

Thanks

Puvendran

Jul 20 '05 #2
pu************* ******@btfinanc ialgroup.com (Puvendran) wrote in message news:<d5******* *************** ****@posting.go ogle.com>...
Hi,

We have encountered deadlock on a table which is used to generate
sequential numbers for different categories eg typical entries

Category Value

TRADE_NO 1456
JOB_NO 267
....

The applications reference the relevant category applicable to them
and update
the Value accordingly. This is table is very small, occupying 1 page.
However, it has no index as it was not seen to be appropriate for a
table this size.

However, can someone please advise whether

1. An index is required for row level locking
2. If an index on a table as small as above is likely to reduce the
deadlock rate.

Also, please consider the following but which I am not sure is
relevant for above query.

We noted that when we migrated the database concerned from SQL 6.5 to
SQL 2000, using DTS, that the database was NOT strictly in SQL 2000
format for non clustered indexes (NC) ie the clustered key was not
part of the NC index until the clustered index was rebuilt.

Given this should I just rebuild this table with a fake index and drop
it thereafter.

We are aware of the different techniques used to avoid deadlocks (eg
tables accessed in same order etc) and have , as much as possible,
implemented those practices.

I thank you in advance for any help you may be able to offer.

Thanks

Puvendran

Puvendran,

As far as I am aware an index is not required to implement row-level
locking, and as you are clearly aware an index on a table this size is
pointless (I doubt the optimizer would ever choose to use it).

The presence of any index would probably increase any tendency towards
deadlocking, since it will lengthen the transaction time (the index
pointers need to be updated as well as the data), and one of the
deadlock avoidance techniques is to keep transactions as short as
possible.

Surely, though, it would be simple to test all this out? Just
implement row-level locking, with and without an index, and see what
happens.

I'm not sure I understand your second observation - the clustered key
was not part of the NC index? Maybe someone else with more experience
of SQL Server than myself can answer this one.
Jul 20 '05 #3
Philip Yale (ph********@bto penworld.com) writes:
As far as I am aware an index is not required to implement row-level
locking, and as you are clearly aware an index on a table this size is
pointless (I doubt the optimizer would ever choose to use it).
An index is definitely helpful in a table as Puvendran's, since if there
is no index, SQL Server will have to put a shared table lock on the table
to be able to find the row to update. Once the row(s) is located, that lock
can possibly be released (although I don't know if that really happens),
but as long as as the exclusive lock is held on the updated row, the
next guy that wants a sequence number for a different item wil be block,
because he can't get the table lock.
The presence of any index would probably increase any tendency towards
deadlocking, since it will lengthen the transaction time (the index
pointers need to be updated as well as the data), and one of the
deadlock avoidance techniques is to keep transactions as short as
possible.


I would expect that the index keys to be stable and not be updated, so
this would not be issue.

--
Erland Sommarskog, SQL Server MVP, so****@algonet. se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 20 '05 #4
Erland Sommarskog <so****@algonet .se> wrote in message news:<Xn******* *************** @127.0.0.1>...
Philip Yale (ph********@bto penworld.com) writes:
As far as I am aware an index is not required to implement row-level
locking, and as you are clearly aware an index on a table this size is
pointless (I doubt the optimizer would ever choose to use it).
An index is definitely helpful in a table as Puvendran's, since if there
is no index, SQL Server will have to put a shared table lock on the table
to be able to find the row to update. Once the row(s) is located, that lock
can possibly be released (although I don't know if that really happens),
but as long as as the exclusive lock is held on the updated row, the
next guy that wants a sequence number for a different item wil be block,
because he can't get the table lock.


But it's a 1-page table. I remain to be convinced that the optimizer
would do an index lookup on this, since this would require a minimum
of 2 I/Os (one for the index page, one for the leaf node). I'll test
this out myself, but I would expect a single-page table scan
(technically a clustered index scan, but it's scanning the leaf pages,
not doing an index seek), which will lead to a shared PAGE lock during
a read operation (which will in reality be equivalent to a table-level
lock, although no lock escalation to table-level will be required),
and an exclusive PAGE lock or ROW lock (depending on the lock strategy
employed) during an update (again, a page lock would be equivalent to
a table-level lock in this particular example).

The question seems to be about how to implement row-level locking
(since this would undoubtedly improve concurrency), and unless someone
knows why it can't be done I'd suggest simply using the WITH ROWLOCK
clause as part of any select or update statement.
The presence of any index would probably increase any tendency towards
deadlocking, since it will lengthen the transaction time (the index
pointers need to be updated as well as the data), and one of the
deadlock avoidance techniques is to keep transactions as short as
possible.


I would expect that the index keys to be stable and not be updated, so
this would not be issue.


Fair point, since the index would probably be keyed on Category, and
these will not change. I still don't see what benefit an index would
offer, though, other than referential integrity by acting as a primary
key constraint.
Jul 20 '05 #5
ph********@btop enworld.com (Philip Yale) wrote in message news:<e9******* *************** ***@posting.goo gle.com>...
Erland Sommarskog <so****@algonet .se> wrote in message news:<Xn******* *************** @127.0.0.1>...
Philip Yale (ph********@bto penworld.com) writes:
As far as I am aware an index is not required to implement row-level
locking, and as you are clearly aware an index on a table this size is
pointless (I doubt the optimizer would ever choose to use it).


An index is definitely helpful in a table as Puvendran's, since if there
is no index, SQL Server will have to put a shared table lock on the table
to be able to find the row to update. Once the row(s) is located, that lock
can possibly be released (although I don't know if that really happens),
but as long as as the exclusive lock is held on the updated row, the
next guy that wants a sequence number for a different item wil be block,
because he can't get the table lock.


But it's a 1-page table. I remain to be convinced that the optimizer
would do an index lookup on this, since this would require a minimum
of 2 I/Os (one for the index page, one for the leaf node). I'll test
this out myself, but I would expect a single-page table scan
(technically a clustered index scan, but it's scanning the leaf pages,
not doing an index seek), which will lead to a shared PAGE lock during
a read operation (which will in reality be equivalent to a table-level
lock, although no lock escalation to table-level will be required),
and an exclusive PAGE lock or ROW lock (depending on the lock strategy
employed) during an update (again, a page lock would be equivalent to
a table-level lock in this particular example).

The question seems to be about how to implement row-level locking
(since this would undoubtedly improve concurrency), and unless someone
knows why it can't be done I'd suggest simply using the WITH ROWLOCK
clause as part of any select or update statement.
The presence of any index would probably increase any tendency towards
deadlocking, since it will lengthen the transaction time (the index
pointers need to be updated as well as the data), and one of the
deadlock avoidance techniques is to keep transactions as short as
possible.


I would expect that the index keys to be stable and not be updated, so
this would not be issue.


Fair point, since the index would probably be keyed on Category, and
these will not change. I still don't see what benefit an index would
offer, though, other than referential integrity by acting as a primary
key constraint.

Okay, humble pie time. Still, I don't understand what I'm seeing,
though, and coming from a Sybase background it wasn't what I expected
to see at all.

Having run a few simple tests, I found the following:

CREATE TABLE [GroupTable] (
[GroupName] [char] (10) COLLATE Latin1_General_ CI_AS NOT NULL ,
[GroupID] [int] NOT NULL ,
CONSTRAINT [PK_GroupTable] PRIMARY KEY CLUSTERED
(
[GroupName]
) ON [PRIMARY]
) ON [PRIMARY]

insert grouptable values ('Admin',334)
insert grouptable values ('User', 2314)
insert grouptable values ('Web', 714)

This gives us a single-page table (well, 8-page if you want to be
strict about extent allocation), with a primary key on GroupName.

The following query uses the clustered index (no surprise, since it's
there), but I was surprised to see it SEEKing rather than SCANning:

select groupid from grouptable where groupname = 'user'

|-Clustered Index Seek(OBJECT:([Northwind].[dbo].[GroupTable].PK_GroupTable]),
SEEK:([GroupTable].[GroupName]=[@1]) ORDERED FORWARD)

As expected, there are 2 logical page reads (one for the index page,
one for the leaf page):

Table 'GroupTable'. Scan count 1, logical reads 2, physical reads 0,
read-ahead reads 0.
Dropping the primary key and then re-running the query gives the
expected table scan:

|--Table Scan(OBJECT:([Northwind].[dbo].[GroupTable]),
WHERE:([GroupTable].[GroupName]=[@1]))

and the number of logical page reads has dropped to 1 (scan of a
single page):

Table 'GroupTable'. Scan count 1, logical reads 1, physical reads 0,
read-ahead reads 0.

This is all more or less what I expected to see, but I couldn't
understand why the optimizer would choose a clustered index seek over
a tablescan simply because the index happened to be there. I compared
the showplan cost estimates and was surprised by the following:

With Clustered Index With No Index
Est Rowcount 1 1
Est Rowsize 11 21
Est I/O Cost 0.00632 0.0187
Est CPU Cost 0.000080 0.000041
Est Cost 0.006408 (100%) 0.037660 (100%)
Est Subtree Cost 0.00640 0.0376

Clearly the estimated total cost with the clustered index is less than
without it, but on a table of this size I'm afraid I just don't
understand why. Any offers?
Jul 20 '05 #6
Philip Yale (ph********@bto penworld.com) writes:
Okay, humble pie time. Still, I don't understand what I'm seeing,
though, and coming from a Sybase background it wasn't what I expected
to see at all.


If Sybase is still sticks to page locks as its lowest level of granularity,
then I can understand that it does not make sense in that context.

However, since version 7, MS SQL Server has row locks, and this is all
about concurrency.

Run this in one query window:

CREATE TABLE [grouptable] (
[GroupName] [char] (10) ,
[GroupID] [int] NOT NULL ,
-- CONSTRAINT [PK_GroupTable] PRIMARY KEY (GroupName)
)
insert grouptable values ('Admin',334)
insert grouptable values ('User', 2314)
insert grouptable values ('Web', 714)
go
begin transaction
declare @next int

update grouptable
set @next = GroupID + 1,
GroupID = GroupID + 1
where GroupName = 'Admin'

waitfor delay '00:00:10'
select "next" = @next
commit transaction
go

The WAITFOR here stands in for some other time-consuming processing.
While the second batch is running, run this from another window:

begin transaction
declare @next int

update grouptable
set @next = GroupID + 1,
GroupID = GroupID + 1
where GroupName = 'User'

select "next" = @next
commit transaction

Note that this second batch does not complete until the first completes.

Now, drop the table and uncomment the PK constraint, and rerun the two
queries. Notice now that the second query window returns instantly.

--
Erland Sommarskog, SQL Server MVP, so****@algonet. se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 20 '05 #7
Erland Sommarskog <so****@algonet .se> wrote in message news:<Xn******* *************** @127.0.0.1>...
Philip Yale (ph********@bto penworld.com) writes:
Okay, humble pie time. Still, I don't understand what I'm seeing,
though, and coming from a Sybase background it wasn't what I expected
to see at all.


If Sybase is still sticks to page locks as its lowest level of granularity,
then I can understand that it does not make sense in that context.

However, since version 7, MS SQL Server has row locks, and this is all
about concurrency.

Run this in one query window:

CREATE TABLE [grouptable] (
[GroupName] [char] (10) ,
[GroupID] [int] NOT NULL ,
-- CONSTRAINT [PK_GroupTable] PRIMARY KEY (GroupName)
)
insert grouptable values ('Admin',334)
insert grouptable values ('User', 2314)
insert grouptable values ('Web', 714)
go
begin transaction
declare @next int

update grouptable
set @next = GroupID + 1,
GroupID = GroupID + 1
where GroupName = 'Admin'

waitfor delay '00:00:10'
select "next" = @next
commit transaction
go

The WAITFOR here stands in for some other time-consuming processing.
While the second batch is running, run this from another window:

begin transaction
declare @next int

update grouptable
set @next = GroupID + 1,
GroupID = GroupID + 1
where GroupName = 'User'

select "next" = @next
commit transaction

Note that this second batch does not complete until the first completes.

Now, drop the table and uncomment the PK constraint, and rerun the two
queries. Notice now that the second query window returns instantly.


This doesn't surprise me at all, and Sybase would do the same (yes, it
does have row-level locking if chosen). Are we saying that SQLServer
will only (can only?) use row-level locking if the is a primary key
constraint on the table?

What was really surprising me before was that the optimizer was
choosing a more expensive solution (index lookup costing 2 logical
reads, instead of a table scan costing 1 logical read). The Query
Plan estimates show that it expected the index lookup to be cheaper,
but I believe the actual results confirm that this expectation was
wrong. I can see that at this scale the differences are negligible,
and if the row-level locking option is only available with a PK in
place then the index lookup is clearly preferrable. However, the
optimizer is a "machine" (of sorts), and I would expect it to apply
costing rules consistently. Couldn't the best solution be achieved,
though, without a PK (forcing a tablescan) and modifying the update
to:
update grouptable WITH (ROWLOCK)
set @next = GroupID + 1,
GroupID = GroupID + 1
where GroupName = 'User'

I realise all this may be of little or no consequence, but it would
help with my understanding of the SQLServer optimizer versus that of
Sybase.
Jul 20 '05 #8
Philip Yale (ph********@bto penworld.com) writes:
This doesn't surprise me at all, and Sybase would do the same (yes, it
does have row-level locking if chosen). Are we saying that SQLServer
will only (can only?) use row-level locking if the is a primary key
constraint on the table?


No. If you submit the version without the clustered index, you will see
that it has an exclusive lock for RID resource. RID is a row id, and
occurs only in heaps. There are also intent-exclusive locks on table
and page level. In the version with the clustered index in place, the
RID resource is changed to KEY, but the intent locks are still there.

In fact, you would have the same result if row locks was all there
was. When the second update comes along, it must read all rows in the
table, to find if the row matches the WHERE condition. But there is
one row in the table it cannot read, because this row is locked, and
therefore the second update is held up here.

When you have an index in place, the second update does not have to
read all rows to find matching rows.

Exactly how the optimizer avoids this pitfall, I don't know, but it
may be as simple that the optimizer stops looking for plans once
it has found one which is good enough.
--
Erland Sommarskog, SQL Server MVP, so****@algonet. se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 20 '05 #9
Erland Sommarskog <so****@algonet .se> wrote in message news:<Xn******* *************** @127.0.0.1>...
Philip Yale (ph********@bto penworld.com) writes:
This doesn't surprise me at all, and Sybase would do the same (yes, it
does have row-level locking if chosen). Are we saying that SQLServer
will only (can only?) use row-level locking if the is a primary key
constraint on the table?
No. If you submit the version without the clustered index, you will see
that it has an exclusive lock for RID resource. RID is a row id, and
occurs only in heaps. There are also intent-exclusive locks on table
and page level. In the version with the clustered index in place, the
RID resource is changed to KEY, but the intent locks are still there.

In fact, you would have the same result if row locks was all there
was. When the second update comes along, it must read all rows in the
table, to find if the row matches the WHERE condition. But there is
one row in the table it cannot read, because this row is locked, and
therefore the second update is held up here.

When you have an index in place, the second update does not have to
read all rows to find matching rows.

Exactly how the optimizer avoids this pitfall, I don't know, but it
may be as simple that the optimizer stops looking for plans once
it has found one which is good enough.


When you have an index in place, the second update does not have to
read all rows to find matching rows.
Not strictly true. The clustered index only directs the optimizer to
the *PAGE* on which the row is located, since the index node rows in a
clustered index only contain the first key value of the target page at
the leaf level. (This is not the same as a non-clustered index, which
would direct the search to the individual record). Thus, with a
clustered index seek you will still have to read all rows on the
target page to find those which match / don't match. Because of this,
I still maintain that the clustered index lookup is more expensive
than a single-page tablescan, even with row-level locking, since you
have to read both the index node page and the entire leaf page (at
least 2 logical reads), as opposed to just a single logical read by
scanning the 1-page table.
Exactly how the optimizer avoids this pitfall, I don't know, but it
may be as simple that the optimizer stops looking for plans once
it has found one which is good enough.


This isn't (shouldn't be) the way optimizers work. They consider ALL
possible plans, then slect the "cheapest". It's the definition of
"cheapest" which is probably the stumbling block here. As the Query
Plan stats showed a few posts back now, the optimizer truly believed
that the clustered index lookup would be cheaper. It was the
STATISTICS IO output that resulted from actually running the query
which showed that, in I/O terms at least (which is usually what the
optimizer would place most emphasis on), the clustered index lookup
was twice as expensive as the tablescan.

It may be that the SQLServer optimizer is biased towards using a
clustered index if one is available, since in most tables a clustered
index SCAN is at least as good as a tablescan, and a clustered index
SEEK is almost always better. Perhaps it's just the 1-page table
scenario that's the exception to the rule?
Jul 20 '05 #10

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

Similar topics

1
5447
by: Arska | last post by:
Hi Is it possible to force row level locking in one or more tables in some database. We have some problems when SQL Server decides to choose page- or table-level locking. We are using SQL Server 2000. Best regards Aarno
1
4044
by: Fardude | last post by:
ACCESS 97, Pessimistic Record Locking!??? Does Access 97 allow record level Pessimistic locking? In other words, when user A is editing a record (has it locked) and User B tries to edit it (attempts to lock it), user B will get an error saying this record cannot be locked now. It seems like Access 97 is doing optimistic record level locking. In above scenario user B, is allowed to edit the record but when tries to
0
1273
by: Deano | last post by:
I use the Access 2000 MSI Wizard from Sagekey and they don't know if the bug documented on page 32 of the Access 2000 Developer`s Handbook Volume 2: Enterprise Edition still affects the runtime. Apparently page locking is invoked when using the Access run-time record than record-level locking. This also affects Access 2000 but if you patch Access the bug is fixed. I really don't know about the runtime though. Does anyone know if...
2
2213
by: Deano | last post by:
I use the Access 2000 MSI Wizard from Sagekey and they don't know if the bug documented on page 32 of the Access 2000 Developer`s Handbook Volume 2: Enterprise Edition still affects the runtime. Apparently page locking is invoked when using the Access run-time record than record-level locking. This also affects Access 2000 but if you patch Access the bug is fixed. I really don't know about the runtime though. Does anyone know if...
2
3138
by: Peter | last post by:
(I've tried this Q in the ms forums without response. See how it goes here.) Using A2003 but I guess this is not version-specific... If I want to implement row/record level locking on a split database where do I need to set this option. Is it sufficient to set it in the frontend database for record-level locking to apply to the backend tables. Or must I also set it in the backend mdb database instead or as well (which is never...
1
1673
by: jv | last post by:
Hello, I'm using A2K and am trying to make sure that my program only locks one record at a time and I don't seem to have any luck getting that to happen. In the database options, I've selected "Open Database Using Record-Level Locking" and the default record lock setting is "Edited Record". My forms' record lock setting is also "Edited Record". With the above settings, I get page-level locking. Can pessimistic
13
2670
by: Owen Jenkins | last post by:
Following on from an earlier post... I can reliably corrupt a record by doing the following ... Open two separate but identical front ends on one PC each linking to the same back end. Edit a records in one front end and leave it unsaved. Edit the same record in the other front end and save the change. Save the change in the first front end - this pops up the Write Conflict message to which I click Save.
11
3469
ollyb303
by: ollyb303 | last post by:
Hi, I have a problem with a multi-user db in Access 2000. The db is for logging calls to my company and will be used by up to 30 people, though currently around 10 are using it. I have split the db into front/back end and each user is using a local copy of the front end, connected to the back end via our network. It was all working fine when we tested it (across 2 different sites) and had no problems, but now, some new users are...
1
2225
by: Paul H | last post by:
I have an Employees table with the following fields: EmployeeID SupervisorID Fred Bob Bob John Bob Mary Bill Bill I have created a self join in the relationships window, with
0
8528
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,...
0
9072
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. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
1
8782
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,...
0
8786
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 choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7621
agi2029
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...
1
6453
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 instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5807
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();...
0
4321
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...
0
4547
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?

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.