I have been searching for more info on this and found out quite a lot about it; however, I am still wondering how to connect the front ends that will be in different machines to the back end that resides on server.
I know that when you split a database, the wizard asks where to save the first front end. But how about if you have many?
i thank all for helping with the issue of mulitple users. after i did the splitthe database using the wizard. i noticed the tables lookes diiferent. but how do i put the front ends for users in their document since am on a thin client enviromemt. or how do i transfer the front from the end. do i have to write codes?? thanks
Hi. I would like to split my database which is used by various people on a shared drive.
Is it possible to specify a relative path to the linked tables in the back end?
Otherwise, if people access the shared drive via different drive letters, it fails.
Also, I like to keep a copy of the database myself. With absolute paths to the back end tables, I can't simply copy both sections from one place to another - as the links fail.
I recently decided to split my database into a front end/back end environment. What I noticed though was a huge slow down in performance. One subform in particular takes 5-8 seconds to load, as opposed to less than a second before the split.
I know that splitting the database comes highly recommended in this forum, but the slowness is unacceptable. I especially want to split the database so I can execute changes quicker.
By the way, I have read several threads that recommend turning off the name autocorrect feature. I did this in the front and back end but did not notice a diference. I also compact/repair the database regularly.
The other thing I tried was creating an MDE file, as I was told they run quicker. Unfortunately, I am told by Access that it cannot be created. I believe from what I have read that I have too many forms that have attached modules.
For now, I am going to merge the database back into one file. But if anyone could offer some advise, I would like to pursue a split again.
I split a database and created a backend but now I dont need it and I accidentally deleted the backend while I was updating the file folder and it was on the network so it's gone for good.
Is there a way to reverse splitting a database so it no longer requires the back end?
I have a split database - frontend and back end sitting on a server. If there are only going to be absolute maximum 4 people using this database at a time - is there any good reason for it to remain split.
The reason I ask is that a few people may want to "take it home" to work on it and being non-computer savvy people have a lot of trouble re the concept of linking the front end to the back end.
I have a database (already splitted in FE/BE) which Clients use on site.Part of the service we offer is Outsourcing: We do all the capturing and when they login on their side, it downloads the latest BE file for them to use "Read-Only".
However we added a new module in which half of the data on a particular table needs to be completed by the Client.So we need for the table to be splitted in such a way that they can capture their info on the form and when we log in on our side, it has to download the data they entered in the same way as when they login and download the data we captured.
Was thinking about adding a 3rd database file to the mix with just one table and in some way link that table to the existing table for the new module. But the intermediate link I created is not updateble.
I've recently downloaded the Goods template database from Microsoft [URL]. It's basically a inventory, invoice, purchase order system and is enough to fulfill my office needs. However, I seem to be running into an issue when I'm trying to split the database using the built in tool.
The "the database cannot be opened because vba project contained in it cannot be read..." error pops up when I click on "Access Database" button in an attempt to split the database. I also tried to do it manually, but noticed that none of the queries and most of the forms don't show up on the list when I'm trying to import queries, forms, etc.
I have spent the last couple of hours looking through the forums but have managed to get myself really confused. Lots of questions, sorry - if anyone can point me in the right direction with one or two of them, I would be hugely grateful!
I have a database in a shared folder on the network at work. It is due to start being used by users other than myself in future weeks, and I see here that it's sensible to split things into a FE and a BE.
1. My initial problem is that I have a nagging memory of being told that we're not supposed to save anything on the individual computers hard drives. Can a split leave both the BE and the various copies of the FE on the shared drive, or does this negate the reasons for splitting in the first place?
2. Additionally, with little space left on the shared drive itself, it's possible we'll not have the room to put 10+ copies of the FE on it anyway. If I just split the database into the BE and ONE copy of the FE which everyone accesses, will the BE at least be made more secure by the split, even if the FE is still vulnerable, and performance isn't improved?
3. If no sort of split is possible, are there any alternatives to splitting?
Lastly, some questions for if we ARE able to split and put the FE on each computer:
(I would be keeping the BE and the "master" version of the FE on the shared drive. All tables in the BE and queries, reports and forms for the "user interface" in the FE. Hopefully this is roughly what I'm supposed to do).
4. With a split database, what happens with compacting? Presumably the BE of the database can be compacted as normal, but what happens with all the versions of the FE? Does each user have to be responsible for compacting them individually? Does an FE even need compacting if the design is unchanged?
5. Does splitting affect what happens if two people either open or amend a record at the same time, or is that still just governed by the record locks setting in Tools (which would need to be set before splitting presumably)?
6. If the design of the FE changes (but none of the underlying tables, queries etc. are touched), do I just give each user a copy of the new version, or does something more complicated have to happen (ie. does the whole splitting process have to take place again)? What about if new tables are added to the BE, or if existing tables / queries are amended? Can I just issue amended versions of the FE that interacts with the new tables as needed?
7. I have drop down lists and combo boxs in the forms in the FE that use tables to populate them. Will it cause problems that these tables are in the BE - such as impractical amounts of time before combo boxs show their options? (The table has to be in the BE (I think?) because the user updates the content of these tables / combo boxs through one of the other forms in the FE)
Many, many, many thanks if anyone can help me out with any of these.
I split a database (without first making a copy of it) on my local machine and put the front end on a shared network drive. now no one can open any of the forms since the back end is on my machine.
is there a way to undo this or to split the database on the network drive so that users can get in?
i want to avoid having to redo the database from the ground up.
I'm in the middle of developing a database for our engineering group to track projects. I've got a question:
I'm using Runtime because none of our group has MS Access loaded on their system. So, I'm providing a link to the participant to download the free Runtime Software and providing a Shortcut to the database in the shared area.
My question is, when I split the database and provide the users with the front end do they still require runtime? Do I still provide them the link to download the free Runtime software and if so, do I save both the back and front end with the .accdr extension? I'm assuming that since they will have the front end on their systems individually they will no longer require the Shortcut.
The way the system is currently, it seems that only one user is permitted in the database at a time as it is locked out. I would like for more than one user to be able to access the database at a time. I've set the Default Open Mode to Shared so I'm not sure why it gets locked down when a user is accessing it.
Hallo everybody I have an Access databse in which I have devided the tables into backend and frontend by using the Database Splitter wizard. Then if I create any tables in the frontend Access file then thease tables are visible only in the front end of this system , not from other systems if I put the back end in network. its ok for some tables , but now I have a table which I have to put in the shared backend , but if I cerate in the front end it is visible only in front end and if I create in backend it is visible only in backend. how to send a table in the front end to backend after database splitting is over, so that I can access this table from other systems. if it is possible please help me. Thank you. Kiran
I have created a db for a nonprofit counseling org. I had created the first half, mostly administrative tasks, called Phase1, and put the BE on a network drive and the FE on multiple users. Now in developing the clinical portion, Phase2, I linked to four of the tables in Phase1 BE file.
Now I tried to split Phase2 the same way as Phase1 and got an error "Subscript out of Range". I think because of already having some external links in it. I checked for the file and Access actually created the BE file for the new phase2, all of the tables are in it minus the four I was linking to. But, access didn't create a FE file. The original still has all of the objects, tables and forms etc. My question is; can I link to the tables in the new BE file even though those tables still exist in the original file?
In the database I have a main form with subform "frmitinerer" . Using a button on the main form open form "frmrelation." After entering the new daily haul and closing forms refresh the data in the subform "frmitinerer."Code on the button is on click event
I've inherited a rather messy database which and I need to split it in order for us all to be able to enter data at the same time without problems however I get the following message..Index or primary key cannot contain a Null value..It happens at the table that contains the majority of the data (typical) but I cannot understand what could be causing it. I've check Null Primary Key field and removed all of the "required" statuses out of the fields but still no luck.
I tested on a backup database from a couple of days ago and it worked. Only difference is I've added a few bits and bobs since then and 1 field in the table it's stalling on but this field doesn't contain any null values either and I've tried deleting that field in my test database but made no difference.
I'm trying to import data from our current Database Pro v1.0 DB to an Access DB that I'm creating.
Our DBPRO is essentially a flat-file data entry program. It has a "subform" for history events that isn't actually in it's own table, but all concatenated in a single [History] field.
Basically, when viewed in DBPRO, it's broken into different records, yet it's actually stored as one. DBPRO uses °, ±, □, and 0's to separate the different "fields", but Access can't seem to break it down automatically.
When I export the data to a CSV file, everything else comes through with minimal problems. The [History] field, of course, comes in as a huge block of concatenated records.
I've attached an example of this below. I included only the field in question, ([History]), and the primary key, ([Last Name/Cust]). The first tab in my example is a single record, recently imported. The second tab shows how I need it to be, broken into multiple records.
Is there anyway I can split these records, while maintaining the primary key? It's my goal to have all the other information in one table, and the history records in a separate one.
Thanks so much for your help! I've researched all over, and just can't seem to find a similar problem, or solution. :(
I am attempting to split my Access Database and will upload the back-end portion to a SharePoint site. No matter what I do, I continue to get a "Not a valid file name" error.
I am splitting a database and have created the Back end already. When I create the front end and link to the tables on the back end... The front end does not link to all the tables in the back end. The list that comes up when creating the linkings does not show all the tables in the back end. What would cause this?
Getting ready to split a DB. No security really needed... Only the ability for multiple users needed. From what I have read here so far it seems best to use a MDE file on the front end and MDB file on the back end. One question is still not answered... I guess I will find out when I load the front ends on different stations.. BUT... I would like to know what to expect. I am assuming that each computer that I load the front end on I will have to go through and link the backend. Correct? I read a MS Knowledge base article about a form to do this... Is this only possible if you use the "developers edition" ??? Whats the common method for this task? Thanks Curtis
I have created an application that uses all the 'normal' factors of an access app. My forms are triggered by events that initiate some vba code which executes and then does something. No big whoop, we are all doing this; but I am going freakin' insane keeping up with changes. The users are using this app in a "live" test enviroment and the changes/updates are coming in quicker than I can type. "This field is not right it should read like this" Well I can't change it until everyone gets out - they don't like this answer:D
I jumped in before thinking a few versions ahead and did not split the database :eek: I have read a lot of posts here and other sites and I can tell that I need to split this app but am a bit hesitant. From what I can gather I would have a Front-End - houses all my queries and forms Back-End - houses all my tables
I have a few modules, where would they need to go so that I can work on them independent of what my users are doing? I would give each user a copy of the FE or make it available via network drive; would I then keep a seperate copy of my FE to make changes? If yes, does this mean my modules would be in the FE? Can I split the db now that it has been in live production? What are some common errors that I should look for prior to? I tried to split the db one time before, but my drop down list box(s) on the forms would not work. They are controlled by a query, not any code. Error msg stated could not find xyz sorry I don't recall the exact error
I need the ability to change, work on and update at will AND NOT effect my users.
I have been reading a lot about splitting databases on this forum. I still have some questions. 1) Will the FE (Front End) still show the tables? 2) Will users still be able to edit the forms, reports, etc.? 3) Will my code be hidden 4) Will all the users have up to date data showing when they open the Database? 5) Can more than one person open and input data in the database at the same time?
I also want to make an MDE copy, do I split first or make the MDE and then split?
The whole point is the following: I want the people (maximum 10) that will be using this database to only be able to do enter and view data. They should be able to generate the reports but not create new reports. I only want ONE person to be able to edit the forms, code, and reports. How would I do this.
I've split a database and the backend relationships are still intact but the front end they are not and it looks like this is causing a problem. Is this usual?
I've currently got a date of birth field in my database, but would like to query on just the birth month. Can anyone tell me how to do it. Do I have to create another field which separates out the month, and if so, how do I do that.
Hi everybody, I have been spending the last few days trying to find a way through the "access security Maze" which I believe I have just done. I have been following the "Ms Access Security Faq to the letter" and just now, I can open the database via a desktop shortcut including a custom workgroup address and I think everything is working fine. Now, I am trying to organise the next step which is splitting the application.
GHudson stated: I find it easier to start out with one database that has everything in it [including the security]. Then I copy the db. Rename them so that one is the front end, one is the back end. The security will still be in both since they are exact copies. Then remove the shared tables from the front end, remove everything else from the back end [except the tables that will be shared]. Then relink the shared tables from the front end to the back end.
Using custom shortcuts will make it easier for the users to open the front end with the correct workgroup. You can customize the shortcuts target field with all the required file and workgroup info.
I Understand prtty well what's being said but am getting a bit confused of where and how the different part of the application should be organised on the network:
*The back end file should be on the network drive(drive F) -That's fine...
*The front end should be distributed only on the station using the application:
1) Does that mean that I could place the FE on the F drive for a short while and ask the different user to copy the application and past it on their own drive and then delete the FE of the share drive.
2) I will have to use the custom shortcut with the specific work group on each station. Should they all have the same shortcut which would mean that there is only one FE on the F drive and not make much sense or Should the shortcut link to the FE application save on their drive which doesn't make much sense either because they could open the DataBase without the shortcut with their own "default" Workgroup and wouldn't be secure anymore.
I apologize for my confusion and have probably missed a basic step in my reasonning but if anybody could redirect me in the right direction, I would really be gratefull.