[AccessD] Record deleted by user

John Colby jcolby at colbyconsulting.com
Sat Sep 6 19:21:09 CDT 2003


Jim,

Are you talking about the FE/BE with the FE downloaded daily?

I create a shared directory on the server.  This directory on the server
will be mapped on the workstation to a given drive letter.  I use X: where
possible simply because over the years I have found most companies networks
use the drive letters up from D:, and X: is usually available.

Inside that directory I create a dir named for the client's app.  I do that
for my own convenience as a developer, more on that in a minute.

I place both the FE and the BE in that named directory inside the shared
directory on the server.  Where possible I then map the shared directory as
a drive to the local machine such as X: - that is the directory below where
the FE/BE resides.  This simplifies matters as I can link the FE to
X:\MyApp\SomeBE.MDB and then all the workstations can download the FE
without having to relink before use.

I build a batch file that I place in that same directory that simply does an
MD to make the directory, then an XCopy to copy the FE down.  The MD makes a
directory on the local hard drive, perhaps C:\ClientAppName.  If the
directory already exists fine, otherwise it gets built.  The XCopy then
copies the FE into that dir and then calls Access to open the FE.

Go around to each machine that will use the db.  Map the X: (or whatever) to
the shared server directory.  Create a shortcut to the batch file on the
server.  Run the batch file (shortcut) one time to create the directory,
download the app and my framework and run it.  This just ensures that
everything works.

That's pretty much all there is to it.

Of course in my case I also have my framework to distribute, so the batch
file also copies C2DbFramework.MDA to the Windows directory.

Doing things this way makes distribution of a new version dead simple.
Upload a new framework or FE (or both) to the server.  The next time the
user clicks on the shortcut on their desktop they get the latest.

Remember up above I mentioned my convenience as a developer?

Now on my dev machine at home I do the same thing.  I create a mapped drive
D:\Dev and share it.  I then create a directory named for each CLIENT'S
application.  Thus I have on my dev machine d:\Dev:\DISNew, D:\Dev\BPDB,
D:\Dev\LDA etc etc.  I map Dev as X:\ and I now have X:\DISNew, X:\BPDB,
X:\LDA etc where DISNEW is an app for Disability Insurance, LDA is an app
for Learning Disability association, BPDB is an app for Beacon Financial
Group etc.  In essence my X drive is a directory on my D: drive mapped out
over my network and back in to the same machine (I could put it on my server
if I wished of course).  Each dir inside of X: belongs to a different
client.  Assuming that I get to use the X: drive mapping at each client,
things just work.  I can link the FE to the BE and ship it to the client
without relinking.  If I have to use a different drive letter on the client
workstations then I have to also map that drive letter on my machine
(perhaps Y:), although it is still mapping the D:\Dev directory on my
development machine.  So far only a single client has already used the X:
drive mapping and forced me to move to another drive letter.

I think it might be possible to do this same thing using the substitute
command from DOS.  Someone mentioned that awhile back.

John W. Colby
www.colbyconsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jim Lawrence
(AccessD)
Sent: Saturday, September 06, 2003 6:19 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Record deleted by user


Hi John:

What would be the best way to distribute an application that way? I have
never used this way before but a set of circumstances seem to warrant this
method.

Any insight would be greatly appreciated.
Jim

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John Colby
Sent: Friday, September 05, 2003 7:15 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Record deleted by user


> I would create the table in a temp MDB file unless the FE will be replaced
on a regular basis.

The FE is downloaded every morning when they click a hotlink to a batch file
on their desktop.

>  I would try prefilling the select table with one record for each of the
main records and doing an inner join.

I tried that.  There are problems starting with when to build the records?
There are thousands of these records so I really only wanted to generate
records for the specific records they wanted to print, which is why I am
doing it this way to start with.

>The only time then you'd delete a selected record is if the main record
gets deleted.

Yea, I really ran into this because I was going into the table and manually
deleting the select records.  It PROBABLY won't be something that ever crops
up but it's a nasty one if it does.

John W. Colby
www.colbyconsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jim Dettman
Sent: Friday, September 05, 2003 7:26 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Record deleted by user


John,

 Couple of comments.

<< I create a table local to the FE with two fields:>>

 I would create the table in a temp MDB file unless the FE will be replaced
on a regular basis.

<<The odd behavior comes if I delete the records in the new Selected table.
If I build a query that displays the original table joined to the Selected
table, when I delete any records in the Selected table, the fields in the
query from the Selected table display the words "Deleted" and I can no
longer enter any data in that field because I get a JET error "record
deleted by user".  I have to requery the query and then I can again create
new records.>>

  Access displays #Deleted when it can't figure out which matching record it
can use.  I believe you'll find that it's because your using the outer join.
The same problem occurs with ODBC linked tables at times.

  I would try prefilling the select table with one record for each of the
main records and doing an inner join.  The only time then you'd delete a
selected record is if the main record gets deleted.

  As for inserts into the selected table, you might want to handle those
manually via code and keep the selected table's PK out of the underlying
query.


Jim Dettman
President,
Online Computer Services of WNY, Inc.
(315) 699-3443
jimdettman at earthlink.net

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John Colby
Sent: Friday, September 05, 2003 2:07 PM
To: AccessD
Subject: [AccessD] Record deleted by user


I am trying to implement a "selected flag" system for a particular form.  I
create a table local to the FE with two fields:

SelectedID Long
Selected Boolean

I modify the form's query to do an outer join between the pk of the original
table and SelectedID.
I add a check box to the form bound to the Selected field.

Whenever the user clicks the check box a record is created in the new table,
the SelectedID is set to the PK of the original table and the Selected field
is set true.  All fine so far.  Printing works fine - filter on records with
a join to this table and selected = true.

The odd behavior comes if I delete the records in the new Selected table.
If I build a query that displays the original table joined to the Selected
table, when I delete any records in the Selected table, the fields in the
query from the Selected table display the words "Deleted" and I can no
longer enter any data in that field because I get a JET error "record
deleted by user".  I have to requery the query and then I can again create
new records.

This is an issue because the FORM's recordset works until I delete a record
in the selected table, then the checkbox FOR THAT RECORD ceases to work for
no apparent reason.  The reason of course is this problem discussed above.


John W. Colby
www.colbyconsulting.com


_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com





More information about the AccessD mailing list