I am developing a access database front-end, where the database resides in SharePoint list. There is a Attendance Table with AttDate and StaffID columns apart from other columns.
Want to achieve: Only one record is added per staff for a day. i.e. only One Attendance is recorded in a day. When user tries to enter attendance of same staff again on same day, he should get error.
When the back-end was in Access file, I had created an index with 2 columns, and made the index "allow unique values only". The screen looks like this.
Now when, I am moving my back-end to SharePoint, I was expecting same functionality. But, moving Tables to SharePoint using Access 2013 wizard did not create the index. Hence I thought creating it manually will solve the problem. So, I created an index with 2 columns, See screenshot below.
When I entered data, it still allows multiple values , see Screenshot
below
Please help, as to what can be the solution to this problem. I am
allowed to change existing table structure, if the solution so
demands. Any workaround will also be helpful.
SharePoint indexing is more about making it faster to retrieve and search for items in SharePoint. It has nothing to do with unique constraints.
You're going to have to add something to your SharePoint instance that will perform this check for you.
You haven't mentioned whether you're using SharePoint on-line or on-premise. You do say that you're using the Access front-end. This typically means you'll need to use an event receiver which will involve C# (or VB.NET) programming.
Workflows wouldn't prevent the duplicate row from being saved
JavaScript would help if using SharePoint UI, but won't prevent services
You do mention that you're using an Access front-end. Maybe you can add some business logic in your Access file?
Hope this helps
Related
I have an MS Access 2016 application that a few people use in one department. I know this whole thing has web dev written all over it but this access database has been their process for a while and there is no time right now to switch over.
Recently, a different department wants to use this application, but having their own copy. Currently, if I need to make changes, I'll make the changes in a copy of the app, they send me a current version when I'm ready to import their data, I import it and send them back a new one. However, currently I copy the data table by table and past it into the new database. This is inefficient and tedious, and now with 2 sets of data I'd be doing this for, that's crazy. There's over 20 tables so I don't want to have to manually copy over 40+ tables across the 2 apps for even the smallest change like altering a message to the user.
I know I can copy the code so I can avoid importing the data, but sometimes for big changes I'll change over 15-20 vba files.
So, a couple questions:
1.Is there a way to generate insert statements for the entire database that I could run in a script? So when I create the new copy I just upload 1 file and it populates all the data?
2.Are there any kind of dev tools that will help this process? Right now I'm thinking that it's just a downfall of creating an MS Access app, but there must be some way that people have made the "new release" process easier. My current system seems flawed and I'm looking to have a more stable process.
EDIT:
Currently I have all my data stored locally, attached to the same access file as the front end. Since I will have 2 different departments using the same functionality, how do I manage the data/the front-end? These 2 departments should have their own access file to enter data using the forms, so having 1 front end between the 2 departments won't work.
Also, should I create 2 separate back-ends? Currently I would have nothing to distinguish what is being inserted/changed/deleted from one department from the other. If I were to attach a field specifying who entered the record, that would require a complete overall of all my queries which I don't have the time for as there are deadlines I need to meet.
First thing is to split the database. There is a wizard for this.
Then you can maintain the frontend without touching the real data.
Next, consider using a script to distribute revised versions of the frontend. I once wrote an article on one proven method to handle this:
Deploy and update a Microsoft Access application in a Citrix environment
I have a project that is developed in CakePHP with MySQL. The problem is daily 2-3 records are getting entered in the 'products' table with 0 values in the fields.
There are 2 ways of entering data via application - Front-end & Admin panel. Both forms are authenticated (via ACL) and having validations (client side and server side). But not able to find how these blank records are coming on daily basis.
Any help regarding, in which area I have to look to solve the issue, would be appreciated.
How come people say rows are inserting in the database automatically?.
A computer doesn't do any thing by its own unless you direct it to do.
Current Question where it stands*
I see two possibilities:
1.There might be an event scheduler running at a fixed time in your DB. Explanation
Referenced from here
2.Someone might be doing it without your knowledge.
Does anyone have any pointers on how to go about creating a "wizard interface" using Access 2010? I need a sequential set of forms that will be capable of branching the flow based on answers from the user and data found in the database. I have used Access before for some CRUD/Reports type of applications, but in this case I can't seem to wrap my head around how to get started on such a complex machine.
Before anyone suggests it, I cannot use anything but Access due to client requirements.
I feel your pain ... working with Access gets so difficult where there are complex requirements.
Gather and document the requirements
Make sure you've teased out every possible wrinkle and contingency from the client, and put it into a flow chart or something.
Extract the models
Figure out what models are being used -- customers, addresses, vendors, products, etc. These will have to be created as tables or adapted to existing ones.
Extract other variables
What could potentially change over time and/or what will the client want to be able to change via an admin screen? You'll have to decide which of these variables to put into tables, and which are ok in the code (form logic and/or VBA).
Design the tables for the wizard views
I imagine you'll want a wizard screens table, where each row corresponds to a step; each should have (other than an id column) a previous screen column, and a form name or form template name column. You'll need a second table choices with a many-to-one foreign key linking back to screens; each row here will correspond to a possible outcome of the view, and the target next step in the wizard.
Design the forms
Finally, design the forms corresponding to each wizard step or template, pulling data from the structures in 1-4 as needed.
i have 2 questions when i use access:
i create a form with comboBox and calenders, i want to choose an employee
from combobox and from date and to date and when i click ok i will send these
parameters to a query to return the result in a query (result is the calculation
of it's salary).
i know how to release an access project to be useful to user that can't
access tables and queries only forms.
is there any way to change the access project from release mode to development
one, because supposed that an error occurred, how to solve it without loosing
my data.
Note: i don't have client/server i develop a program and i release it and
give this release to the user, after a specific time this user tell me that
an error occurred, and he need data inserted from this program to database.
i can solve this problems and release another version of program, but the
main problem is how to take all data from the old program to the new one.
-- You can reference form control in a query:
SELECT FROM MyTable
WHERE EmployeeID = Forms!MyForm!cboEmployee
AND SomeDate BETWEEN Forms!MyForm!txtDateStart And Forms!MyForm!txtDateEnd
You could also build an SQL string and use it as the record source for a form or in VBA.
-- Access should be split into front-end (forms, reports, etc) and back-end (data). When you make changes to the front-end, you create a new mde or accde and send that to the users. The data stays on a server in the back-end.
See: http://msdn.microsoft.com/en-us/library/aa167840(v=office.11).aspx
EDIT
From your comments, it seems that each application has a single user, if this is the case, splitting is not essential, but it can still be a good idea. The user will get two databases, one for data and one for forms etc and only the one for forms gets replaced. You will need to include a routine to locate and link the back-end tables.
However, if this is not possible, an mde or accde does not hide the data, you can send your revised copy and include a routine to import from the previous mde/accde.
EDIT 2
There are wizards that will split your database for you and link the tables. Where you find them varies slightly from version to version, but they are under the menu item Database Tools. The only problem with this is that the linked table holds the location for the back-end, which is on your computer, not on your users computer. Linked tables are how you access data in the second database. These act as if there are tables in the first database, except you cannot change them. Unfortunately, linked tables hold the location of the back-end, so this will have to be changed if you are sending it to a users. You can either write code, or show your user how to use the linked table manager. This may lead to confusion and may not be worth the effort for one PC. (See also http://www.alvechurchdata.co.uk/accsplit.htm)
Alternatively, you can split the database on your PC and make all the changes to forms etc that you want, then add some code that will import the tables and other data for the user into your new copy. The user will follow the instructions in your code to import the tables. As an aside, you will find that development is a lot safer on a split database. You should also decompile from time to time, which you can find at http://www.granite.ab.ca/access/decompile.htm.
If you want to protect your code, you can create a compiled version of this new copy, the extension for a compiled Access database is *.accde, for 2007 onward and *.mde for prior versions. This is what I thought you meant by 'i know how to release an access project'.
I have a lookup list that is used in a custom solution to provide information about a specific location. This list includes columns of type People and Groups.
Given the quantity of locations that will be available I'd be very keen that the list is maintained and imported from an Access database. I do something similar with my configurations list which works great. It just means I can rapidly deploy all configurations across different environments.
The problem I have encountered is that it doesn't seem to handle columns of data type People and Groups. The lookup is not available in Access. From what little i have found online, I'd not even sure if this is possible. This article suggests that Access automatically creates a link to the USerInfo table. Even with this link, I cannot look up values.
Can someone please let me know if this is possible or a limitation and cannot be achieved when linking a list to Access?
This absolutely possible, and MS Access should automatically link any dependent lists when you import a parent list that has lookups.
Check to make sure you don't have multiple UserInfo lists linked, like UserInfo1, UserInfo2, etc. If so, delete all your linked SP lists and relink.