How do I create a signup page?

[MdHaziq]

Hello forum,



I have to create a database.

I am new to this.

I need to break it down into smaller pieces.

Right now I want to do a sign up page for those employees who want to use the database for the first time.

I want to save the data that the users enter in the form to my table when the user clicks enter.

I do not know how to do that. I have attached the MSAccess doc.

Can someone please help me?

Thanks,

Yours Sincerely,
Haziq

[ranman256]

after the data is entered, click Save,
you run an append query.

the query takes the items in the form and add them to the table.
use the BUILDER to pick items from the table as source fields to be added.

[Micron]

Are you going to let just anyone who can open the db become a user? If so, you ought to have an AutoExec macro determine if they are already registered (people will probably re-register simply because they forgot their password). If they are not, present the sign up form. Have a button on the form with a click event to save the record. If they are, then don't open the sign up form but provide a starting point from which to interact with the db - maybe a switchboard form. I would not use a navigation form since so many people seem to post about issues when trying to get them to work. BTW, the way you have it, I will be able to see anyone's sign up information by cycling through the records.

Personally, I would ditch the idea altogether. An admin person should be entering user credentials into the user table, and if the startup routine doesn't find them, they don't get in. This means passwords are not required, thus they are not vulnerable to exploitation. As long as you use a bit of forethought, you should be able to keep most people out who shouldn't be getting in (such as hiding the nav pane, disabling keyboard shortcuts, disallowing the shift by-pass) though an Access db will never be 100% bullet proof for some people.

EDIT: as an after thought - your current process will also require you to implement a password changing and/or recovery feature, which is another whole chunk of design work. If you choose not to bind the controls of a sign up form (as you currently have designed) this becomes an ever bigger task.

[Forbes]

Hey, technically, this is a duplicate post, if you review your original question I posted something that may be of use to you, simply create 2 tables

tblPendingUsers
tblActiveUsers

When the application launches have it check the %USERNAME% against the tblActiveUsers, if it is not preset have the application send the username to tblPendingUsers (you can also have this email yourself as a way of notifying that a user needs to be approved for active) If you need more information from the users on signup simply create a form that loads with the fields you need from them and have this form add the record to tblPendingUsers with the %USERNAME%.

Once the user has been moved to tblActiveUsers the application will verify it against your table and let the user in, this also avoids having to create a password for users as if they cannot access the PC workstation, they cannot access your program.

[MdHaziq]

Thanks for your foresight.

It really saves me the trouble to create something that will not work in the end.

The reason my manager wanted employees credentials when they withdraw or stock in is to keep a record for checking or auditing.

Is there a way I can do this?

[MdHaziq]

Okay,

Where do I put the query in the textbox?

[MdHaziq]

Well explained man,
Sorry I have not seen my previous threads. Going to look at all of them now.

Does this work on a shared PC?

It is overwhelming for me. Could you create a video lesson for me to follow through? Or a sample program will be a great help too.

Thanks so much

[Forbes]

Sorry it will not work in the end for you, please mark the other as solved if this is the main thread.

[Micron]

I can elaborate, which will be a lot of information. First, I'd like to know if each user is going to be running Access from their own computer, and not using Access RunTime.

[MdHaziq]

Everyone here has their own ID and pass to access their accounts to use the computers in the company.
Everyone who works here uses their own ID and pass, they access the same computer during office hours.

Hope this helps.

[Micron]

Well, that doesn't tell me if they're using Run Time. I'll assume not since I had the following drafted in Note Pad in the meantime:

I don't understand what you mean by withdraw or stock in. If just that means who logs in I'd say that's pretty much useless. If you want to know who makes modifications to data or enters data into the tables, you could employ all or perhaps just part of the following:

- splitting the db into an FE/BE (front end/back end) where each user has their own FE copy should be done regardless. Some will do this when design is complete. I'd split it at the beginning, having one FE that I'm designing, to ensure no problems arise at the last stage. You don't want to find out on release day that there is a network performance issue.
- in tblUsers (a user table) have fields for user information (LoginID, Fname, Lname, EmplNo, Level, Active, Email, etc.). Level is one that you would have to think about for your case. In mine, it held either User, Supervisor or Admin (from tblLevels). User or Supervisor access was restricted from certain parts of the db; Admin could do anything.
- use an AutoExec macro to run a startup routine (code in a standard module). I would call this module mdlStartUp. IIRC (if I recall correctly) a macro can only call a function, not a sub, so this function would be like Public Function Startup(). I would decide what I want it to control before worrying about the order of checks. For instance, there's no point in checking if the BE is not in its authentic place (meaning someone has copied the BE, perhaps onto their desktop) if it's an unauthorized user. Here's some checks you might want to incorporate:
* is this an active and authorized user?
* has someone started an update of the db's main data source tables - assuming you will have such a process?
* has the Admin started a lockout/shutdown?
* is the BE locked out because tables are being added or modified?
* open form frmTimer (there may be a process you want to run regularly, such as checking to see if the Admin has started a lockout/shutdown)
* if everything OK, open a splash screen (to hide the usuall Access logo on startup)
- Google to find the function fOSUserName and add it to mdlStartup or a module that will hold a host of your custom functions. This function gets the network login ID of the user (NOT their password). You'd list these in the user table field LoginID. There is also one to get the machine (computer) name of the user if you think that would be useful.

To the point of your original question, the startup routine would run fosUserName (Google it) and pass it to your user variable, like: strLoginID = fosUserName
Then use DLookup to see if that user is in tblUser: strUserID = DLookup("LoginID", "tblUser", "LoginID = '" & strLoginID & "'")
If the function returns no value, the person attempting to log in isn't in the table, and the routine advises them to call the db administrator or supervisor to gain access. If you want to allow them access, you add their info to the user table. There is a similar function out there to get the machine ID that they log in with, but for allowing access and logging who enters or edits data, it's unnecessary in my opinion. The only thing I found it useful for was to know who might have a lock on a table and what PC they did it on, since they'd often move around to different stations.

For any table that matters, you have fields like CreateBy or EditBy (possibly along with the create and/or edit date fields) and write the value of strLoginID as the person who made the change. Or you could write their EmplNo (employee number) from the user table. The most elegant way of doing any of this is to create a user object upon startup and assign all these values to it as properties of the user object. I think that might be too advance for you at this point.

Obviously, you will want to take steps to prevent anyone from circumenting this process (such as adding themselves to the table) so you must take steps to secure the db as much as you think is required, knowing that it will never be 100% secure. It depends on the knowledge and level of intent that anyone might have. That is a whole other topic.

[MdHaziq]

Oh wow.
I will need to process all the information.
Thx for explaining to me.

I will get windows user to get username.
That will be good enough for now.

[MdHaziq]

How do I mark as solved?

[Micron]

coloured bar just under your question title; "Thread Tools" drop down; "mark this thread as solved".

[MdHaziq]

I dont see any coloured bar under my question.

Only reply to Thread.

I am using my phone..