 | |
2010 Data macro capture user
comp.databases.ms-access comp.databases.ms-access
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: 2010 Data macro capture user -
03-30-2011
, 10:51 AM
|
David-W-Fenton wrote: "Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote in news:Cjijp.3015$aV3.284 (AT) newsfe02 (DOT) iad: Now, build a query like: SELECT tblDummy.ID, (fosUserName()) AS FUser FROM tblDummy; Save above in back end as qryUser You don't need a dummy table at all. This should suffice: SELECT (fosUserName()) AS FUser You don't actually need a FROM clause in the SQL statement. Oh really? That's no longer a requirement? Very interesting! It's about time! |
instance (which seems like a likely inflection point to me). Just
checked and it does NOT work in A97, so it must have been A2000 that
introduced that capability.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#12
| |||
| |||
|
|
I'm not going to dump my OneRow table anytime soon. One common usage is to add an ALL row to a combo box: SELECT ID, Descr FROM lookuptable UNION ALL SELECT 0, " ALL" FROM OneRow Leaving out the FROM OneRow provokes an error about at least one table is needed. |
table in my app and SELECT TOP 1, which is highly optimized for an
indexed field.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#13
| |||
| |||
|
|
Marshall Barton wrote: Bob Barrows wrote: David-W-Fenton wrote: "Albert D. Kallal" wrote Now, build a query like: SELECT tblDummy.ID, (fosUserName()) AS FUser FROM tblDummy; Save above in back end as qryUser You don't need a dummy table at all. This should suffice: SELECT (fosUserName()) AS FUser You don't actually need a FROM clause in the SQL statement. Oh really? That's no longer a requirement? Very interesting! It's about time! I'm not going to dump my OneRow table anytime soon. One common usage is to add an ALL row to a combo box: SELECT ID, Descr FROM lookuptable UNION ALL SELECT 0, " ALL" FROM OneRow Leaving out the FROM OneRow provokes an error about at least one table is needed. Oh! So they fixed it in the query builder but not in the data source editors ... |
You'd likely have to use a saved query without the FROM clause, and
then in the UNION you could use the query name in the FROM clause.
Kind of defeats the purpose, of course, but it does mean you don't
need a dummy table in that case.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#14
| |||
| |||
|
|
?"elgin" *wrote in message news:3ceb6275-8375-4f1c-be76-32bbf18893b6 (AT) i4g2000pro (DOT) googlegroups.com... This way, it will track any changes to the table(s) however they are made; form, macro, or VBA. Also, once the Data Macro is in place, it is independent of the front end forms, code, and versions. It's like an SQL trigger. Set it and forget it. What I believe I need is a way to track which computer/user'sinstance of thefrontendinitiated the change. Ok, in the back end database, create a dummy table with one column and one record: tblDummy:ID * * * (autonumber) tblDummy  ummy * (text)Add one record to above. Now, add the following VBA code (you can do this to both front end, and back end - this code not needed in back end, but if you ever need to edit tables direct in back end, you need VBA code in both front end + back end: You can get thecurrentnetwork logon name with:http://www.mvps.org/access/api/api0008.htm And, thecurrentcomputer name with:http://www.mvps.org/access/api/api0009.htm Now, build a query like: SELECT tblDummy.ID, (fosUserName()) AS FUser FROM tblDummy; Save above in back end as qryUser Now add a table trigger to the before update: LookUp A Record In qryUser * Where Condition = [id] = 1 * * * * *Alias * * SetField (tblCustomers.EditBy,[qryUser].[Fuser] There is a screen shot of above macro here:http://nrfr5a.bay.livefilestore.com/...wKf4gN7C3T3-I2... So, the above query could also have computer name in addition to the above network logon name. Note that the before change trigger event is quite light weight, and it does not allow adding records to other tables, but you could well use the above code in the after update event, or have a last edit + last computer edit column in the above and then in the after update event, append the data to a log. Just keep in mind that thecurrentrecord in context for the after update event is read only, where in before change event, you can modify columns. (and while thecurrentrecord in the after update event is read only, you can create a new instance of it if you needed, but I do not recommend as such) -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada Pleasenospam_kal... (AT) msn (DOT) com |
The query based on the dummy table calls the CurrentUserID() function,
which is on the frontend, to get the current frontend user. Then the
front end crashes!
Frontend crashes when the named data macro calls this CurrentUserID()
function:
Option Compare Database
Option Explicit
'--------------------------------------------------------------------------------------------------
' This code is used assign variables to the user information and hold
it in memory
' so that it can be used as the user navigates through the database
' Created By: Richard Rensel
' Created On: 19 Feb 2002
' Modified On: 19 Feb 2002
'---------------------------------------------------------------------------------------------------
Public Type UserInfo
GroupID As Integer
AccessID As Integer
Active As Boolean
Password As String
UserID As Integer
UserName As String
SecurityID As String
End Type
Public User As UserInfo
Public Function CurrentUserID() As Integer
CurrentUserID = User.UserID
End Function
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.