473,326 Members | 2,061 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

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

Safely deleting a db record with php

Hi,
I hope I'm not OT.

I have the following issue:
I want to delete a record from my db with a php script. Let's say I'm auth'd
and I want to delete the record id 440. With a simple form (get or post), I
send the id to my script and delete the record (DELETE FROM table WHERE
id=some_validated_input).

The problem is if I'm a nasty guy I just write my own form and delete any
record I want (since I'm auth'd) by just sending another id.

Is there any way to make arbitrary record deletion non-trivial in php? I'm
thinking about a hash function to replace the real db id (DELETE FROM table
WHERE record_hash=validated_form_hash), if possible without adding an
awfull lot of server side computation.

How do you guys deal with that kind of situation?

Thanks,
--
MaXX

Apr 19 '06 #1
19 2110
You should have more detailed authorization - not only auth'd
non-auth'd, but every user must have its access information, so system
can recognize who is that man who wants to delete.

Then you should specify (for example) owner of a record - add a column
to your table, which contains identifier of user, who is allowed to
delete it (or do any other operation with it).

If you need even more details, you may consider definition of usergroups
(need one extra simple table).

MaXX wrote:
Hi,
I hope I'm not OT.

I have the following issue:
I want to delete a record from my db with a php script. Let's say I'm auth'd
and I want to delete the record id 440. With a simple form (get or post), I
send the id to my script and delete the record (DELETE FROM table WHERE
id=some_validated_input).

The problem is if I'm a nasty guy I just write my own form and delete any
record I want (since I'm auth'd) by just sending another id.

Is there any way to make arbitrary record deletion non-trivial in php? I'm
thinking about a hash function to replace the real db id (DELETE FROM table
WHERE record_hash=validated_form_hash), if possible without adding an
awfull lot of server side computation.

How do you guys deal with that kind of situation?

Thanks,

Apr 19 '06 #2
Jiri Fogl wrote:
You should have more detailed authorization - not only auth'd
non-auth'd, but every user must have its access information, so system
can recognize who is that man who wants to delete. The problem in my particular case, is that the system can't know who will
delete as there is no explicit ownership. The table in question is a log
and the creator is a script.

Your suggestion can be very usefull for another area of my project...

Another idea is to only allow the php script to set a deleted flag wich only
hide the record and wipe or undelete them by other means ...
Then you should specify (for example) owner of a record - add a column
to your table, which contains identifier of user, who is allowed to
delete it (or do any other operation with it).
If you need even more details, you may consider definition of usergroups
(need one extra simple table).

The database (postgresql) is already aware of this, the rights are set by
groups (creators INSERT, R-O users SELECT, Admins UPDATE[mark as
read]/DELETE). Some major events have a "protected" boolean to avoid
deletion by the php script. When I want to get rid of those I use PgAdmin
or psql as superuser to delete them.

Time to rethink the system...

Thanks,
--
MaXX

Apr 19 '06 #3
MaXX <bs******@skynet.be> wrote in
news:e2**********@talisker.lacave.net:

The problem is if I'm a nasty guy I just write my own form and delete
any record I want (since I'm auth'd) by just sending another id.

in your database, add a column called "keystring" and index it. populate
it with 18 characters or so (write a PHP function that does this at the
same time you enter the info in the database). So, this 'keystring' for
record 1 might be '9jfhdsufs8ywre' while record 2 might be
'agsadgiwqegiqw'.

Since the keystring is indexed, you can delete it from your DB by calling
"DELETE FROM so_and_so WHERE Keystring='9jfhdsufs8ywre'" Chances are
pretty damn slim that someone will be able to guess any keystring and
therefore alter records.

I use this technique often, especially when allowing users access to pick
up files.

See ya

Apr 19 '06 #4
MaXX wrote:
Hi,
I hope I'm not OT.

I have the following issue:
I want to delete a record from my db with a php script. Let's say I'm auth'd
and I want to delete the record id 440. With a simple form (get or post), I
send the id to my script and delete the record (DELETE FROM table WHERE
id=some_validated_input).

The problem is if I'm a nasty guy I just write my own form and delete any
record I want (since I'm auth'd) by just sending another id.

Is there any way to make arbitrary record deletion non-trivial in php? I'm
thinking about a hash function to replace the real db id (DELETE FROM table
WHERE record_hash=validated_form_hash), if possible without adding an
awfull lot of server side computation.

How do you guys deal with that kind of situation?

Thanks,


Along with the other suggestions:

Make deleted an attribute (column) of the table and then access the data
via a view that filters deleted items. If a record is deleted by
accident, it can still be re-created by changing the deleted attribute.
Some other process may come along and remove the deleted rows at some
regulated time (e.g. after a backup, after so many days, etc.)

-david-

Apr 19 '06 #5
Good Man wrote:
MaXX <bs******@skynet.be> wrote in
news:e2**********@talisker.lacave.net:
The problem is if I'm a nasty guy I just write my own form and delete
any record I want (since I'm auth'd) by just sending another id. in your database, add a column called "keystring" and index it. populate
it with 18 characters or so (write a PHP function that does this at the
same time you enter the info in the database). So, this 'keystring' for
record 1 might be '9jfhdsufs8ywre' while record 2 might be
'agsadgiwqegiqw'.

It's the idea I have, but I need a to find a way to do this with an
absolutly unique "keystring" (md5*/sha1??) to avoid duplicate (may be
extremely rare, but this is the kind of bug you don't want to hunt one
day ;-) ...)

The uniqueness is not realy important in this project but things can
change...
Since the keystring is indexed, you can delete it from your DB by calling
"DELETE FROM so_and_so WHERE Keystring='9jfhdsufs8ywre'" Chances are
pretty damn slim that someone will be able to guess any keystring and
therefore alter records.

[...]
[*] In my knowledge collisions can exist with md5 but avoiding md5 collision
is a WMD vs fly in that case...

Thanks,
--
MaXX

Apr 19 '06 #6
David Haynes wrote:
MaXX wrote:

[...]
How do you guys deal with that kind of situation?
Thanks,

Along with the other suggestions:
Make deleted an attribute (column) of the table and then access the data
via a view that filters deleted items. If a record is deleted by
accident, it can still be re-created by changing the deleted attribute.
Some other process may come along and remove the deleted rows at some
regulated time (e.g. after a backup, after so many days, etc.)

Thanks for the suggestion, I keep that in mind.

--
MaXX

Apr 19 '06 #7
MaXX <bs******@skynet.be> wrote in
news:e2***********@talisker.lacave.net:
Good Man wrote:
MaXX <bs******@skynet.be> wrote in
news:e2**********@talisker.lacave.net:
The problem is if I'm a nasty guy I just write my own form and
delete any record I want (since I'm auth'd) by just sending another
id.

in your database, add a column called "keystring" and index it.
populate it with 18 characters or so (write a PHP function that does
this at the same time you enter the info in the database). So, this
'keystring' for record 1 might be '9jfhdsufs8ywre' while record 2
might be 'agsadgiwqegiqw'.

It's the idea I have, but I need a to find a way to do this with an
absolutly unique "keystring" (md5*/sha1??) to avoid duplicate (may be
extremely rare, but this is the kind of bug you don't want to hunt one
day ;-) ...)


to make a unique keystring, you could always md5 the current unix
timestamp.

if you're concerned about duplicates, load up the keystrings from the
database into an array and see if your newly generated one has any
duplicates with in_array()

Apr 19 '06 #8
MaXX said the following on 19/04/2006 15:54:
Good Man wrote:
MaXX <bs******@skynet.be> wrote in
news:e2**********@talisker.lacave.net:
The problem is if I'm a nasty guy I just write my own form and delete
any record I want (since I'm auth'd) by just sending another id.

in your database, add a column called "keystring" and index it. populate
it with 18 characters or so (write a PHP function that does this at the
same time you enter the info in the database). So, this 'keystring' for
record 1 might be '9jfhdsufs8ywre' while record 2 might be
'agsadgiwqegiqw'.

It's the idea I have, but I need a to find a way to do this with an
absolutly unique "keystring" (md5*/sha1??) to avoid duplicate (may be
extremely rare, but this is the kind of bug you don't want to hunt one
day ;-) ...)


You could define the keystring column as a unique index. If on your
first insert you get back an error (implying a duplicate), then you can
just modify the keystring and insert again. Repeat until success!

Of course, if this is the method you go for, then using some sort of
hash is redundant; you might as well just generate random integers or
strings of a suitable length.
--
Oli
Apr 19 '06 #9
Oli Filth said the following on 19/04/2006 16:01:
MaXX said the following on 19/04/2006 15:54:
Good Man wrote:
MaXX <bs******@skynet.be> wrote in
news:e2**********@talisker.lacave.net:
The problem is if I'm a nasty guy I just write my own form and delete
any record I want (since I'm auth'd) by just sending another id.
in your database, add a column called "keystring" and index it.
populate
it with 18 characters or so (write a PHP function that does this at the
same time you enter the info in the database). So, this 'keystring' for
record 1 might be '9jfhdsufs8ywre' while record 2 might be
'agsadgiwqegiqw'.

It's the idea I have, but I need a to find a way to do this with an
absolutly unique "keystring" (md5*/sha1??) to avoid duplicate (may be
extremely rare, but this is the kind of bug you don't want to hunt one
day ;-) ...)


You could define the keystring column as a unique index. If on your
first insert you get back an error (implying a duplicate), then you can
just modify the keystring and insert again. Repeat until success!

Of course, if this is the method you go for, then using some sort of
hash is redundant; you might as well just generate random integers or
strings of a suitable length.


Integers are probably better, because it will take less work for the DB
to index them.

--
Oli
Apr 19 '06 #10
Good Man wrote:
MaXX <bs******@skynet.be> wrote in
news:e2***********@talisker.lacave.net:
Good Man wrote:
MaXX <bs******@skynet.be> wrote in
news:e2**********@talisker.lacave.net:
The problem is if I'm a nasty guy I just write my own form and
delete any record I want (since I'm auth'd) by just sending another
id.
in your database, add a column called "keystring" and index it.
populate it with 18 characters or so (write a PHP function that does
this at the same time you enter the info in the database). So, this
'keystring' for record 1 might be '9jfhdsufs8ywre' while record 2
might be 'agsadgiwqegiqw'.

It's the idea I have, but I need a to find a way to do this with an
absolutly unique "keystring" (md5*/sha1??) to avoid duplicate (may be
extremely rare, but this is the kind of bug you don't want to hunt one
day ;-) ...)

to make a unique keystring, you could always md5 the current unix
timestamp.

to be sure I've md5'd a concat of the timestamp (2005-11-12
19:11:14.043195+01) and the message and it seem to work at least with a few
hundreds of rows and I don't see how I can get any duplicates. Even if that
(unique constraint violation) the message will be logged again but a
slightly different timestamp...

Now I have a 32 chars unique identifier for each row, a bit too long but it
is doing the job fine.

[...]

Thanks again,
--
MaXX

Apr 19 '06 #11
>I want to delete a record from my db with a php script. Let's say I'm auth'd
and I want to delete the record id 440. With a simple form (get or post), I
send the id to my script and delete the record (DELETE FROM table WHERE
id=some_validated_input).

The problem is if I'm a nasty guy I just write my own form and delete any
record I want (since I'm auth'd) by just sending another id.
Validate they have the authority to delete the record they want
to delete *AT THE TIME OF THE SUBMIT*.
Is there any way to make arbitrary record deletion non-trivial in php? I'm
thinking about a hash function to replace the real db id (DELETE FROM table
WHERE record_hash=validated_form_hash),
You still need to validate that they have the authority to delete the
record *AT THE TIME OF THE SUBMIT*. The owner of the record may have
changed. The person deleting the record may have had the authority
to delete the record yesterday, but he was fired today, or his membership
expired.
if possible without adding an
awfull lot of server side computation.


Add a lot of server-side computation. You had to decide if he had the
authority to delete the record when the form was sent to the user. It can't
be that hard.

Gordon L. Burditt
Apr 19 '06 #12
Following on from MaXX's message. . .

I use a number of approaches
(1) Instead of auto-incrementing ID use a 32 bit random number.
(Obviously you have the creation overhead of making sure you can't
retrieve the record before creating it to catch. the theoretical 1 in
24billion chance of a clash)

This DOESNT solve your problem if any other IDs are available for
inspection. eg a selection table with click on button to delete
functionality because the other IDs can be harvested. AND WORSE if you
use this ID anywhere at all eg a table of click on button to _edit_
functionality the same thing applies.

However it WILL work for customer accounts where individual customers
never get to see a list of other customers. They can't then think let's
change ".../custdetails.php?custid=42" to "....?custid=43"

(2) Keep track of page visiting history in the session and boot out
people coming back via bookmarks without going through the right path.
Here's the outline:
In page 1
$_SESSION['LastPage']='Page1';
At top of page 2 :
if($_SESSION['LastPage']!='Page1'){...

(3) Wrap up each of your actions for each page in a handy object or
array and pop them into the session keyed by a random number. Use this
in your links
<a href="screenserver.php?A=2342542542">Delete record 1</a>
<a href="screenserver.php?A=71452726">Delete record 2</a>
Then in screenserver.php you do (in outline)
$a = $_GET[A];
$action = $_SESSION[actions[$a]];
$action = $_SESSION[actions] = array();
if($action->do=='del'}{....
if($action->do=='edit'}{....
$id = $action->id;
(4) If you want persistent links, for example you send a contact an
email with a "visit http:// ...?A=123435245" in it then do something
similar in a database table.
**** PS ****
I'm not doing much PHP at the minute. I've had the objects for (3) and
(4) working but never bothered to finish them off for public
consumption. If there's anyone who wants to finish them off then you
can probably work out the real email address if you feel like dropping
me a line.
--
PETER FOX Not the same since the cardboard box company folded
pe******@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>
Apr 19 '06 #13
>I use a number of approaches
(1) Instead of auto-incrementing ID use a 32 bit random number.
(Obviously you have the creation overhead of making sure you can't
retrieve the record before creating it to catch. the theoretical 1 in
24billion chance of a clash)

This DOESNT solve your problem if any other IDs are available for
inspection. eg a selection table with click on button to delete
functionality because the other IDs can be harvested. AND WORSE if you
use this ID anywhere at all eg a table of click on button to _edit_
functionality the same thing applies.
All of this is a very poor substitute for validating that the user
in question has the authority to delete the record *AT THE TIME OF
THE FORM SUBMISSION*. If the user with administrator authority
always has the authority to delete *any* record, and a user without
administrator authority cannot delete any record (even his own),
there's nothing wrong with just using trivially-guessable record
numbers. But you need to re-check his administrator status at the
time of the form submission. He might have been fired between the
form being sent (and possibly cached in a browser for a year) and
submitting it.

If the user can only delete *his own* records, then check, when he
submits the form, that he still has the authority to delete it: he
still owns it, his membership hasn't expired, he's still logged in
as the same user, etc.
However it WILL work for customer accounts where individual customers
never get to see a list of other customers. They can't then think let's
change ".../custdetails.php?custid=42" to "....?custid=43"
Someone malicious can still try running through all the numbers.
(2) Keep track of page visiting history in the session and boot out
people coming back via bookmarks without going through the right path.
Here's the outline:
In page 1
$_SESSION['LastPage']='Page1';
At top of page 2 :
if($_SESSION['LastPage']!='Page1'){...


Unless you store which records the last page offered him the chance
to delete, and that it would still offer him the chance to delete
the record that he is trying to delete, this check is ineffective
and spoofable.

Gordon L. Burditt
Apr 19 '06 #14
MaXX wrote:
Jiri Fogl wrote:
You should have more detailed authorization - not only auth'd
non-auth'd, but every user must have its access information, so system
can recognize who is that man who wants to delete.

The problem in my particular case, is that the system can't know who will
delete as there is no explicit ownership. The table in question is a log
and the creator is a script.

Your suggestion can be very usefull for another area of my project...

Another idea is to only allow the php script to set a deleted flag wich only
hide the record and wipe or undelete them by other means ...


The question isn't so much about ownership but authorization. If
deleting arbituary records in the table is not supposed to happen, then
logically it follows that there is a rule governing which records can
be deleted.

Apr 19 '06 #15
Rik
Oli Filth wrote:
> The problem is if I'm a nasty guy I just write my own form and
> delete any record I want (since I'm auth'd) by just sending
> another id.
in your database, add a column called "keystring" and index it.
populate
it with 18 characters or so (write a PHP function that does this
at the same time you enter the info in the database). So, this
'keystring' for record 1 might be '9jfhdsufs8ywre' while record 2
might be 'agsadgiwqegiqw'.
It's the idea I have, but I need a to find a way to do this with an
absolutly unique "keystring" (md5*/sha1??) to avoid duplicate (may
be extremely rare, but this is the kind of bug you don't want to
hunt one day ;-) ...)

You could define the keystring column as a unique index. If on your
first insert you get back an error (implying a duplicate), then you
can just modify the keystring and insert again. Repeat until
success!

Of course, if this is the method you go for, then using some sort of
hash is redundant; you might as well just generate random integers or
strings of a suitable length.

Integers are probably better, because it will take less work for the
DB
to index them.


Instead of trying again and again to insert the record (although it would be
rare to have duplicates, depending on length), why not combine the an
autoincremented index & a key/hash/whatever? On deletion, both would have to
be given: duplicate key's are not a problem, because indexes are guarenteed
unique... Less time in script, but wether it's faster in de DB I have no
idea: you've got a nice small integer as unique number which can be found
very quickly, but you'd have to check 2 fields....

DELETE FROM table WHERE
id=some_validated_input AND
key=other_validated_input
Advantages are that every insertion works, "key"-length can be considarably
shorter (unless you're afraid for brute-force attacks..) and the unique
index/primary key has a logical value.

Grtz,

--
Rik Wasmus
Apr 20 '06 #16
Following on from Gordon Burditt's message. . .
I use a number of approaches
(1) Instead of auto-incrementing ID use a 32 bit random number.
(Obviously you have the creation overhead of making sure you can't
retrieve the record before creating it to catch. the theoretical 1 in
24billion chance of a clash)

This DOESNT solve your problem if any other IDs are available for
inspection. eg a selection table with click on button to delete
functionality because the other IDs can be harvested. AND WORSE if you
use this ID anywhere at all eg a table of click on button to _edit_
functionality the same thing applies.
All of this is a very poor substitute for validating that the user
in question has the authority to delete the record *AT THE TIME OF
THE FORM SUBMISSION*. If the user with administrator authority
always has the authority to delete *any* record, and a user without
administrator authority cannot delete any record (even his own),
there's nothing wrong with just using trivially-guessable record
numbers. But you need to re-check his administrator status at the
time of the form submission. He might have been fired between the
form being sent (and possibly cached in a browser for a year) and
submitting it.

If the user can only delete *his own* records, then check, when he
submits the form, that he still has the authority to delete it: he
still owns it, his membership hasn't expired, he's still logged in
as the same user, etc.


Sorry Gordon, I should have made it clear that each page checks the user
as a matter of course. It didn't occur to me that some people don't do
this.
By the way : It _is_ a good idea to use big random unguessable numbers
for IDs because (a) it *obviously* makes the cracking job harder and (b)
even if you hit a valid number you have no idea whose it would be. Thus
it is a deterrent. Also (probably with more bits in the random number)
it is _essential_ where the user cannot be validated. For example
"Thank you for your custom...To view the progress of your order go to
www..../orders.php?OID=123454345434544"


(2) Keep track of page visiting history in the session and boot out
people coming back via bookmarks without going through the right path.
Here's the outline:
In page 1
$_SESSION['LastPage']='Page1';
At top of page 2 :
if($_SESSION['LastPage']!='Page1'){...

Unless you store which records the last page offered him the chance
to delete, and that it would still offer him the chance to delete
the record that he is trying to delete, this check is ineffective
and spoofable.

There are sometimes cases where persistent state in the database isn't
comprehensive enough. To take a simple example: Your delete page might
be preceded by a warning page about the dangers of deleting "Are you
sure" etc. In which case you code :
$_SESSION['DeleteWarningDone']=1;
in the warning page then at the top of the delete page
if($_SESSION['DeleteWarningDone']==1){...
(But why bother with specific code like this when you have standard page
tracking functions.)

Instead of delete, think of add (or submit order). Checking somebody's
authority is fine, but you need an idempotent method so that duplicate
orders aren't created by mistake.

--
PETER FOX Not the same since the submarine business went under
pe******@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>
Apr 20 '06 #17
>>All of this is a very poor substitute for validating that the user
in question has the authority to delete the record *AT THE TIME OF
THE FORM SUBMISSION*. If the user with administrator authority
always has the authority to delete *any* record, and a user without
administrator authority cannot delete any record (even his own),
there's nothing wrong with just using trivially-guessable record
numbers. But you need to re-check his administrator status at the
time of the form submission. He might have been fired between the
form being sent (and possibly cached in a browser for a year) and
submitting it.

If the user can only delete *his own* records, then check, when he
submits the form, that he still has the authority to delete it: he
still owns it, his membership hasn't expired, he's still logged in
as the same user, etc.
Sorry Gordon, I should have made it clear that each page checks the user
as a matter of course. It didn't occur to me that some people don't do
this.


If you check the user at a matter of course, then you can LET THE
USER SPOOF ALL HE WANTS. And random numbers are pointless in this
situation. If the user is properly logged in (which you check),
and he spoofs, then either he has the authority to delete the record,
which you should allow, or he doesn't, which you'll reject anyway.
If he's not logged in or doesn't have the authority to delete
records, he can spoof *ALL* of the numbers and still won't do any
deletions.
By the way : It _is_ a good idea to use big random unguessable numbers
for IDs because (a) it *obviously* makes the cracking job harder and (b)
If a user can only delete records he has the authority to delete anyway,
cracking attempts are pointless, so why bother preventing it?
even if you hit a valid number you have no idea whose it would be. Thus
If the idea is to inflict random damage, it doesn't matter.
it is a deterrent. Also (probably with more bits in the random number)
it is _essential_ where the user cannot be validated. For example
"Thank you for your custom...To view the progress of your order go to
www..../orders.php?OID=123454345434544"


I don't think I'd feel comfortable implementing such a thing (if
it didn't require a login) if real money was involved. I'd worry
about putting any confidential information (e.g. an order) in
such a system also.

Gordon L. Burditt
Apr 20 '06 #18
Following on from Gordon Burditt's message. . .
it is a deterrent. Also (probably with more bits in the random number)
it is _essential_ where the user cannot be validated. For example
"Thank you for your custom...To view the progress of your order go to
www..../orders.php?OID=123454345434544"


I don't think I'd feel comfortable implementing such a thing (if
it didn't require a login) if real money was involved. I'd worry
about putting any confidential information (e.g. an order) in
such a system also.


Why?
.... IOD=123434343443 is a shared secret no different to a username and
password. The 'must login' approach is (a) cumbersome for the user, (b)
cumbersome for the sysadmin and (c) doesn't give any more security.

--
PETER FOX Not the same since the bridge building business collapsed
pe******@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>
Apr 20 '06 #19
>>>it is a deterrent. Also (probably with more bits in the random number)
it is _essential_ where the user cannot be validated. For example
"Thank you for your custom...To view the progress of your order go to
www..../orders.php?OID=123454345434544"


I don't think I'd feel comfortable implementing such a thing (if
it didn't require a login) if real money was involved. I'd worry
about putting any confidential information (e.g. an order) in
such a system also.


Why?
... IOD=123434343443 is a shared secret no different to a username and
password. The 'must login' approach is (a) cumbersome for the user, (b)
cumbersome for the sysadmin and (c) doesn't give any more security.


Because the ENTIRE shared secret needed for access is sent in a
single email. It is also likely that it will be recorded in browser
history (unlike web logins, where the logout procedure advises the
user to close the browser if it's a public system to get rid of
session cookies). Some browsers manage to leak browser history to
rogue sites using Javascript or Java. Ever notice how physical
credit cards and PINs are sent in DIFFERENT postal mails, usually
several days apart? There's a reason for that.

Yes, there is a difference in security.

Gordon L. Burditt
Apr 20 '06 #20

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

Similar topics

1
by: Mark | last post by:
This question refers to a main form with a continuous form subform. After an error occurs after entering several records in the subform, how can I delete all the data in the main form and all the...
3
by: Nathan Bloom | last post by:
Hi, I have a data entry form (access 2000) that also allows the user to add, update, and delete records from the form. The Delete action is carried out in an event procedure and has the...
2
by: uv | last post by:
Hi! I'm having problems submitting a new record through the form. I'm working with the wizard and I've added a control button to my form for entering entering a new record but for some reason it...
1
by: KC | last post by:
Hello, I am using Access 2002. WinXP, Template from MS called Orders Mgmt DB. I have tweaked this DB to work for our small co. It has worked pretty well up until I made the mistake of deleting...
3
by: deekay | last post by:
I'm using Access 2000 working in DAO at the moment and am having trouble deleting a record from a form that has been filtered. So I'm filtering a form and then when the user selects the record...
46
by: DP | last post by:
hi, i've got a form, with a subform in it. i've got a delete button in the subform. the code i;ve got is; Private Sub cmdDeleteRecord_Click() msg = "Are you sure you want to delete this...
1
by: Pat | last post by:
Hi all, I have a really awkward situation that is causing memory leak problems. I'm passing data to a driver, and unfortunately, the driver code is not something I can change, and it is written...
4
by: sphinney | last post by:
I'm not exactly sure how to start this post. My question is pretty simple, but it will take a little bit of context before I can state it. (And thanks in advance for taking the time to read this!) ...
1
by: Kyosuke18 | last post by:
Hi everyone, I have a problem in deleting a data that is connected on the database.. I tried this code but it shows me an error: Run-time error '-2147217900(80040e14)': Syntax error in string in...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

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

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