I'm trying to think of the easiest way for non-tech users to dump info into a database, without coding my own web application.
Essentially, they are recording subjective phone grading scores for employees.
I linked an Access form to our MS SQL Server database. The only validation I want it -- I want one field, 'employee' - to be validated against a list of employees from say table.employee on SQL Server.
Once the form is submitted it will be written to table.scorecard -- or what have you.
Is this possible in Access? Their standard validation rules don't seem to cover this. Also, is there simply a better way to accomplish this task in general? Thanks
There are two ways to solve this problem.
The simplest is to use a combobox field for your employee information. Use the employee table as the list data source for the combobox and then set the LimitToList property to true. This assumes that you have setup linked table connections for both your employee table and your 'scores' table.
The second solution is to create a foreign key between the employeeId (or whatever the key field is) in the scores table and the employee table on the SQL side. If someone tries to insert an invalid employee, you will get an insert error. Unfortunately, SQL errors tend to be very confusing to most Access users.
If you want to be very through, you could implement both solutions, this would prevent someone going straight to the linked tables and putting in bad data.
I just realized that I am assuming that you are doing proper relational design where the 'scores' table would contain the employeeId rather than a full name. The idea on the form is to have the combobox display the name, but insert the employeeid field.
Related
I am building a project to manage conferences. The database is on an SQL Server on an AWS instance and I am using MS Access as the front end.
I have a table for Events and a table for Exhibitors
These Tables have a relationship from Events.ID to Exhibitors.EventsID
One of my fields on the Exhibitors table is BoothNumber int Not Null
I would like to ensure that we cannot assign a booth number twice for the same event but have the ability to reuse the number for other (future) events.
Our booth assignment is generic: 1 -75 and this is repeated for every event.
Is something like this possible?
Thank you for your help!
If your data is on sql server, put a multi-field unique index on the table design using two or more fields. Sql server then takes care of the rest preventing duplicate entries.
I am working on a project, where a user will select a a table choice on a website. Once the table is selected, the website will then connect to the database and select the table from a server (Server A) under a database (ABC). The website will also have to choose the same table from a different server (Server B) under database (DEF). Also these tables will have the same name, they will have some different data entered into them.
Our goal is to come up with a dynamic SQL Query/Stored Procedure. Multiple table choices can be visible in the website and once the user picks an option, it DYNAMICALLY passes that information to the database to find the two tables and yield a final table that portrays the differences.
MY PROBLEM:
I am having a lot of problem with the syntax and doing this process dynamically. I have searched everywhere for a solution and am struggling with this for more than two weeks.
OUTLINE OF MY PLAN:
Find primary keys and the column names of all the columns in a selected table. Pass this information to a temporary table
Create a SQL query with something like :
SET #SQL = select table1.col1, table2.col1... inner join..
Take care of conditions where :
A. Data is present in one table but not the other
B. Data is present in both tables
C. What if there is no data in one or both tables.
I would really appreciate any help. I am very new to SQL and have been trying my hardest in this project for a while. Please help me and I will do my best to repay you. Thank you very much for your time.
I am planning to move my access database to sql server using SSMA. I have a Column called Eligibility which have drop down list values as shown in Image. After Converting to sql I realized it doesn't have drop down list option. Can anybody suggest what will be the best solution of my situation? Either I can have any other option to design table in SQL which can hold List Values?
You can do one of the following:
Add CHECK constraint to Eligibility field allowing only a set of predifined values to be inserted into that field, as suggested in comment.
Better solution would be to create Eligiblity table (with id and value fields), and reference this table from main table by id field, possibly creating a PK-FK relationship. This way:
a) Only values from Eligibility table would be allowed. b) You could change and add entries in Elibility table without need to change constraint every time. c) A frontend application could use Elibility table to add drop-down functionality.
SQL Server does not work the same as access. It does not have dropdown option for you to choose from.
The proper way to implement dropdown option with SQL Server as database is to have another application as a front-end and let user access through the application. That way it is easier to manage security.
I'm creating an Account table in my project's database. Each account has A LOT of properties:
login
email
password
birthday
country
avatarUrl
city
etc.
Most of them are nullable. My question is, how should I design this in database?
Should it be one table with all those properties? Or maybe should I create two tables, like AccountSet, and AccountInfoSet, where I would store all those 'advanced' user's settings? And last, but not least: if this should be two tables, what kind of relation should be between those tables?
If this is a relational database, then I definitely would not store those properties as fields in the Account table. Some reasons why:
Once your application goes to production (or maybe it's already there), the schema maintenance will become a nightmare. You will absolutely add more properties and having to constantly touch that table in production will be painful.
You will most likely end up with orphaned fields. I've seen this many times where you'll introduce a property and then stop using it, but it's baked into your schema and you might be too scared to remove it.
Ideally you want to avoid having such sparse data in a table (lots of fields with lots of nulls).
My suggestion would be to do what you're already thinking about and that's to introduce a property table for Accounts. You called it AccountInfoSet.
The table should look like this:
AccountId int,
Property nvarchar(50),
Value nvarchar(50)
(Of course you'll set the data types and sizes as you see fit.)
Then you'll join to the AccountInfoSet table and maybe pivot on the "advanced" properties - turn the rows into columns with a query.
In .NET you can also write a stored procedure that returns two queries with one call and look at the tables in the DataSet object.
Or you could just make two separate calls. One for Account and one for the properties.
Lots of ways to get the information out, but make sure you don't just add fields to Account if you're using a relational database.
I have a SQL Server as backend and use ms access as frontend.
I have two tables (persons and managers), manager is derived from persons (a 1:1 relation), thus i created a view managersFull which is basically a:
SELECT *
FROM `managers` `m`
INNER JOIN `persons` `p`
ON `m`.`id` = `p`.`id`
id in persons is autoincrementing and the primary key, id in managers is the primary key and a foreign key, referencing persons.id
now i want to be able to insert a new dataset with a form in ms access, but i can’t get it to work. no error message, no status line, nothing. the new rows aren’t inserted, and i have to press escape to cancel my changes to get back to design view in ms access.
i’m talking about a managers form and i want to be able to enter manager AND person information at the same time in a single form
my question is now: is it possible what i want to do here? if not, is there a “simple” workaround using after insert triggers or some lines of vba code?
thanks in advance
The problem is that your view is across several tables. If you access multiple tables you could update or insert in only one of them.
Please also check the MSDN for more detailed information on restrictions and on proper strategies for view updates
Assuming ODBC, some things to consider:
make sure you have a timestamp field in the person table, and that it is returned in your managers view. You also probably need the real PK of the person table in the manager view (I'm assuming your view takes the FK used for the self-join and aliases it as the ID field -- I wouldn't do that myself, as it is confusing. Instead, I'd use the real foreign key name in the managers view, and let the PK stand on its own with its real name).
try the Jet/ACE-specific DISTINCTROW predicate in your recordsource. With Jet/ACE back ends, this often makes it possible to insert into both tables when it's otherwise impossible. I don't know for certain if Jet will be smart enough to tell SQL Server to do the right thing, though.
if neither of those things works, change your form to use a recordsource based on your person table, and use a combo box based on the managers view as the control with which you edit the record to relate the person to a manager.
Ilya Kochetov pointed out that you can only update one table, but the work-around would be to apply the updates to the fields on one table and then the other. This solution assumes that the only access you have to these two tables is through this view and that you are not allowed to create a stored procedure to take care of this.
To model and maintain two related tables in access you don’t use a query or view that is a join of both tables. What you do is use a main form, and drop in a sub-form that is based on the child table. If the link master and child setting in the sub-form is set correctly, then you not need to write any code and access will insert the person’s id in the link field.
So, don’t use a joined table here. Simply use a form + sub-form setup and you be able to edit and maintain the data and the data in the related child table.
This means you base the form on the table, and not a view. And you base the sub-form on the child table. So, don't use a view here.