Front End / Back End

[Dick7Access]

My main office ask me to put another option in a combo box. I told them that I can't do that as the only thing I can change is my front in, and it would not change everybody else front end. Also as I don't know SQL enough as I just started the studying a SQL course. I don't even want the pass word to get int the router until I know more. I went into what I thought was just my front end and added the option they wanted. I guess I know even less than I thought as the change ended up on there machine. How can that be? Its not fun being dumb.

 

[Ranman256]

Make changes to your master front end.
Test, then email it to all the users.

 

[Dick7Access]

Make changes to your master front end.
Test, then email it to all the users.

Thanks for answering, but I think you mis-understood the question. I don't want to change anybody's front end much less the back end. My question is why did the office front end get my changed, when I changed mine. I am under ( I guess) the wrong understanding of front ends?

 

[JHB]

If the options in the combo-box is coming from a table in the backend, then the new option is available for all users.
If the options in the combo-box is hard coded values then only you can see the new option, (until the other users get a new frontend)
If the options in the combo-box is coming from a local table in frontend then only you can see the new option, (until the other users get a new frontend).

 

[Tieval]

Simple answer here, when a database is split into front end and back end all the mechanics are in the front end and all the data in the back end. The front end contains details of what controls are on a form but the back end has the data contained in the controls.

Unfortunately there is never any advice given about the issues with this as any control based on data is linked now to the back end, for example if you modify the switchboard on a front end it will affect everybody as the table containing the structure of the switchboard will be in the back end.

In the same way, if you have a combo box based on a table the table is likely to have been moved to the back end.

Put simply you need to be very careful with how a database splits into front end and back end, for example switchboard tables must be contained in the front end.

 

[Dick7Access]

If the options in the combo-box is coming from a table in the backend, then the new option is available for all users.
If the options in the combo-box is hard coded values then only you can see the new option, (until the other users get a new frontend)
If the options in the combo-box is coming from a local table in frontend then only you can see the new option, (until the other users get a new frontend).

Thanks for answering.
That was my understanding. If the option, however, is in the back end and the back end has to be on a server, (is that correct) then I thought that I can't changing anything without the password to the back end and using SQL. (Am I misunderstanding something)

 

[JHB]

If the option, however, is in the back end and the back end has to be on a server, (is that correct)

A Backend database doesn't need to be on a server, (it can also be on your computer), but in the case here it is on a server.

... then I thought that I can't changing anything without the password to the back end and using SQL. (Am I misunderstanding something)

Tables can be linked from the Backend to your Frontend database, so you don't need to use SQL.
You only need the password to the SQL-Server if you're "the manager", you don't need it for changing data in tables.

 

[The_Doc_Man]

You can change the contents of tables in the BE if you have access to the tables in the BE for viewing (as, for example, viewing the list in the Combo Box that is driven from a BE table.)

Since you are on a 2013 version, you no longer have per-user table access controls (i.e. individual user selective access). That went away when MDAC was determined to be a security morass that was better avoided. (P.S. I'm not the one who decided it was a steaming hot mess!)

The back-end, wherever it resides, by definition resides on a server even if it is actually just on someone else's machine in a peer-to-peer network with no domain controller. Remember that native Access BE files are just FILES that are accessed via Windows File Sharing, or Server Message Block (SMB) protocol. Now, if the BE is an SQL Server, MySQL server, or some other SQL engine, then it is entirely a different protocol, and in THAT case you could definitely say the BE was on a server.

The situation you describe is exactly why you need to define a separate development/test environment with its own separate BE. You would then be able to fully test new features on a COPY of the live BE. Your test DB would be a copy of the design-master DB. You never convert the design-master to an ACCDE or MDE or whatever flavor of xDE that is appropriate to your version of Access. Instead, you make a prime (and pristine) copy of that file, which you put in a shared area where your users can download a new copy when appropriate. Then offer physical mayhem, maiming, and mauling to anyone who DARES to muck with your pristine public copy. (Which is why you have a second copy of same in an area where no one can easily get to it.)

Before you say .... but my live BE is an SQL Server and I can't make a second instance of the database on it for testing... just remember that you don't have to. You can make an Access BE on your test system and just link to the "real live" BE when promoting your tested version to become the next pristine version.

I also have fixed it so that my "live" system knows (from the CurrentDatabase.Name property and the Environ("ComputerName") call and a couple of other tests) whether it is on the "live" system. If it is, it refuses to run and will exit immediately. Of course, I have disabled the special keys that would allow users to easily bypass that checking.

 

[Dick7Access]

You can change the contents of tables in the BE if you have access to the tables in the BE for viewing (as, for example, viewing the list in the Combo Box that is driven from a BE table.)

Since you are on a 2013 version, you no longer have per-user table access controls (i.e. individual user selective access). That went away when MDAC was determined to be a security morass that was better avoided. (P.S. I'm not the one who decided it was a steaming hot mess!)

The back-end, wherever it resides, by definition resides on a server even if it is actually just on someone else's machine in a peer-to-peer network with no domain controller. Remember that native Access BE files are just FILES that are accessed via Windows File Sharing, or Server Message Block (SMB) protocol. Now, if the BE is an SQL Server, MySQL server, or some other SQL engine, then it is entirely a different protocol, and in THAT case you could definitely say the BE was on a server.

The situation you describe is exactly why you need to define a separate development/test environment with its own separate BE. You would then be able to fully test new features on a COPY of the live BE. Your test DB would be a copy of the design-master DB. You never convert the design-master to an ACCDE or MDE or whatever flavor of xDE that is appropriate to your version of Access. Instead, you make a prime (and pristine) copy of that file, which you put in a shared area where your users can download a new copy when appropriate. Then offer physical mayhem, maiming, and mauling to anyone who DARES to muck with your pristine public copy. (Which is why you have a second copy of same in an area where no one can easily get to it.)

Before you say .... but my live BE is an SQL Server and I can't make a second instance of the database on it for testing... just remember that you don't have to. You can make an Access BE on your test system and just link to the "real live" BE when promoting your tested version to become the next pristine version.

I also have fixed it so that my "live" system knows (from the CurrentDatabase.Name property and the Environ("ComputerName") call and a couple of other tests) whether it is on the "live" system. If it is, it refuses to run and will exit immediately. Of course, I have disabled the special keys that would allow users to easily bypass that checking.

Thank you so very much. That answers a lot of my questions. It also gives me some new question to look into.

 

[chris1976]

Hi All,

I am a real Access beginner and have built (slowly and painfully) a database from scratch. Having completed it I split it into front and back end files and emailed the front end file to my colleagues who need to use the database. They have each saved this onto their desktop while the back end resides on in SharePoint. However, I have found that each person has been left with an independent front end database that does not update into the backend files when changes are made. I have used the linked table manager to establish the links and there are linked to

Car Costing1 C:\User\test\Shareponit\Dpv Team Site-doc /back-end\dbdvp_be.accdb

Which i think that I have done this right but it just doesn't work! Can you help? Let me know if you require further information!
Thanks!!

Chris
:banghead::banghead::banghead::banghead::banghead::banghead:

 

[The_Doc_Man]

Chris, this is worthy of its own thread. Hijacking an older thread (10 months in this case) increases the chance that someone will ignore your post.

The path you are using for the link is on your local C drive so that is correct if and only if SharePoint is ALSO on your local C drive. But that means that to share that data, everyone needs to see your back-end, which cannot be right.

Typically, links to BE files start with EITHER (a) a higher drive letter that is network-mapped to the real shared drive... at our site, we used R, S, T, U, V, W, X, and Y as our network-mapping drive letters OR (b) URS mapping of the form \\Server\share-folder\folder\...\folder\DBName.MDB (or of course ACCDB).

 

[chris1976]

thank you docman i could find how to make and new thread, on my drive it got sharepoint so i thought that was linked to my sharepoint site

 

[The_Doc_Man]

New topic? Easy. Go to one of the main categories like General, Tables, Queries, etc. There should be something there to start a new thread.