beforeDelConfirm and afterDelConfirm events not firing

[Mark]

Hi

I'm using an Access XP (mdb) which links to SQL Server to retrieve and write
data. Data is pulled into front-end tables for editng etc. and then written
back to the server (reducing connections etc. and resulting in blinding
speed).

I have a form (form view) which contains a subform (datasheet) with another
subform as a sub-datasheet all bound to front-end tables. My options are set
to issue warnings etc., but for some reason the beforeDelConfirm and
afterDelConfirm events don't fire on either subform.

I have created a simple form/sub/sub and the events fire fine, but in the
real form they don't fire at all. the onDelete event fires ok though.

Anyone know where the problem might be...

Cheers

Mark

 

[Ken Sheridan]

Mark:

Are you unconditionally setting the return value of the Delete event
procedure's cancel argument to True? If so the BeforeDelConfirm and
AfterDelConfirm events won't execute. To use a custom deletion confirmation
message you'd put something like this in the Delete event procedure:

If MsgBox("Delete record?", vbQuestion + vbYesNo, "Confirm Deletion") =
vbNo Then
Cancel = True
End If

And suppress the system message if the user elects to delete by setting the
return value of the BeforeDelConfirm procedure's Response argument:

Response = acDataErrContinue

Ken Sheridan
Stafford, England

 

[Mark]

Hi Ken

Thanks for replying. No, I only looked at using the onDelete event after I
couldn't get beforeDelConfirm/afterDelConfirm working.

I will strip the code tomorrow and see if I can isolate the problem.

Thanks again

Mark

 

[Mark]

Hello again...

I got rid of the onDelete code (just in case) and put a simple "Stop" on the
beforeDelConfirm and afterDelConfirm. Neither event fires...?

Cheers

Mark

 

[Ken Sheridan]

Mark:

In that case I think you might find that the 'Record Changes' Confirm option
on the Edit/Find tab of the Options dialogue (Tools | Options on the main
database menu bar) is unchecked. If so check it and the events should fire.

Ken Sheridan
Stafford, England

 

[Mark]

Hi Ken...

That was the first thing I checked ('scuse the pun )

Cheers

Mark

 

[dbahooker]

MDB isn't reliable... I think that you should move to Access Data
Projects and not worry about various bugs in the MDB family

-Aaron

 

[Ken Sheridan]

Mark:

You mentioned in your original post that these were subforms. It is the
subforms' event procedures you are using I assume, not the parent form's,
when handling deletions of rows in the subforms' underlying recordsets?

Ken Sheridan
Stafford, England

 

[Mark]

Hi Ken

Thats right, I'm trying to catch the event in the subform that contains the
record.

Cheers

Mark

 

[Mark]

Hi Aaron

I heard from another group (and this was a year or so ago so may be rubbish
by now) that ADP would be phased out sometime soon. Is this still the case?

I have developed many projects using ADP and found that (though developement
time is slightly longer) using a front-end MDE which handles the data using
ADO commands and pass-through queries is a lot faster (we are on a slow
network by the way). ADP is a nice idea in an ideal environment but I found
a bound form takes a lot longer to load in an ADP than an MDE opened
exclusively which copies the data to front-end tables. My clients find (with
SQL Server backend) an MDE using ADO etc. is generally more responsive.

Also, giving permissions on tables/views in order to bind is out of the
question. We use only stored procedures for reading and writing data (no
views at all and no users have permissions on tables). I'm not sure if you
could bind a form (in ADP) to a parameterised stored procedure (I never
really tried), but assuming you can't then having to grant permissions on
tables/views would make an ADP unsuitable for many situations.

General I would use vb.NET and ADO but the platform is dictated by the
client in this situation.

Cheers

Mark

 

[Ken Sheridan]

Mark:

I'm out of ideas on this I'm afraid. It's very puzzling. Sorry I've not
been of any help.

Ken Sheridan
Stafford, England

 

[Mark]

Cheers Ken, don't appollogise though, its all good...

I'll change the approach tomorrow and will have forgottent about it by lunch
)

Cheers

Mark

 

[dbahooker]

it has NEVER been said by anyone that ADP is 'going away'.

ADP has just as bright of a future as MDB does.

ADP is 100 times simpler in development, maintenance and
administration.

Can you even run a MDB-based application over a VPN?

-Aaron

 

[Mark]

It was actually stated in an Access (email) group a couple of years ago
called AccessD if my memory serves me correct. It was "talk" and like most
talk nothing seems to come of it.

As for running an mdb/mde based app over a vpn, why not. If you use ADO as
opposed to linked tables you can do pretty much whatever you like. The mdb
(or mde) is simply a disconnected front-end.

I'm not sure why you think ADP is simpler? To get the full advantage of SQL
Server/ADP combination you need a much wider skill set than simple mdb
(transactSQL etc. etc.).

In a simple environment an ADP is definitely a much better choice (than an
mdb using linked tables etc.) but I'd still like to know more about the
security issues I mentioned below. For now my compromise is mde front-end,
SQL Server back-end, stored procedures, passthrough queries and ADO. It
rocks for stability and the only real negative feedback I have from users
relate to (any) Access front-end (as opposed to VB solutions etc.).

I even recently converted an ADP projects front-end to MDE pulling data into
local tables etc. as mentioned below and the speed difference is so
significant I've been asked to do the same for 2 other projects.

Cheers

Mark
PS - I'd be real interested to know if it's possible to run an ADP without
views or granting permissions on tables.

 

[dbahooker]

TSQL is much simpler because you don't need to teach your developers
TWO LANGUAGES

much wider skillset? NO.

much more FOCUSED skillset? YES.

instead of learning 2 dialects of SQL (access-sql AND tsql) just learn
TSQL

ADP is simpler because I can use Query Analyzer.

And yes.. you can setup roles / groups so that permissions is HELLA
easy to manage.

passthru queries?

aren't you sick and fucking tired of writing the same work arounds?
how do you change the ODBC connection string for SQL passthroughs;
anyways.. using Linked Table Manager? ROFL

by hand?

ROFL

ADP is a superior platform; for development, administration;
optimizations.

MDB is for fucking retards

 

[dbahooker]

you dont have to relink, refresh.. setup connection strings

a single simple connection... I mean; nortwindcs.adp has some pretty
complex connection string / error handling stuff.

I trust Northwinds' code more than Tony Toews and any of those senile
folk that are too fucking stupid to learn TSQL


-Aaron

 

[dbahooker]

and WHAT is this AccessD group btw?

just because some MDB-retard says that it's going away-- it doesn't
mean it's going away.

Lose the training wheels.

I say that MDB is going away.. do you believe everything you read?

 

[Mark]

Wow... You obviously have absolutely no idea what you'r talking about ;@)

I thought as much...

 

[Mark]

You really need to lear more about SQL server...

you dont have to relink, refresh.. setup connection strings

a single simple connection... I mean; nortwindcs.adp has some pretty
complex connection string / error handling stuff.

I trust Northwinds' code more than Tony Toews and any of those senile
folk that are too fucking stupid to learn TSQL


-Aaron

 

[Mark]

I just listen and find out... Thats why I know you have absolutely no idea
what you are talking about... Funny little man )