We have an in-house program at the company I work for, and inside of MS Access we link all of our tables to our three databases. However; in order to create new routes for students, someone needs an isolated copy of our program to work with that won't impact the actual database.
After deleting the linked tables, importing them all locally, and saving the .mdb I can no longer change values inside of most forms. For example:
A drop down menu with a list of possible route codes for a student will appear. Usually you can select one. You are no longer able to, and in the bottom left hand corner you see "this recordset is not updateable".
I'm a bit new at this, but I can't imagine why importing the tables would break anything. I wouldn't expect any key violations to occur (like I might when linking tables), or anything of that nature. If anyone can point me in the right direction it would be much appreciated! Thanks!
Access can handle a compound primary key on a linked table or view. The important thing, of course, is to make sure you're telling Access the right fields to use. It's common for Access not to get the primary key info when you're linking to a view (perhaps the ODBC driver doesn't pass that info along?), but I bet it can happen with tables too.
Not sure if these pics will help, but hopefully it can point you in the right direction. Here's a linked view, as you can see in this picture:
If you open it in design view, you can see that there are no primary keys:
which means that the table isn't editable (the add new button is greyed out):
So I run this command to tell Access to use a compound primary key on the linked view:
CurrentDb.Execute "Create Unique Index PrimaryKey On View_AssnsWithSorterField([Serial No], AssignmentDate)"
If you open the linked view in design view again, you can see the compound primary key:
and now the add new button appears.
You said that you tried to add a compound primary key but Access wouldn't allow it, which sounds like there's something about the table's data or structure that prevents it from using that key. How about creating an empty copy of the table in the backend database, then try linking to that? If that still doesn't work then maybe there's a unique constraint, or a trigger, or something else on the table that causes Access not to like making it updateable. Conversely, if it links fine and you can add/edit records in the linked blank test table, then it must be data in the real table that's causing the issue.
Sometimes if you cut down a copy of the table into smaller chunks (like maybe just start with the primary key columns alone) and gradually rebuild it piece by piece, you eventually hit on the thing that makes Access not let it be updateable.
One other possibility, of course, is a problem with the driver itself. The ODBC drivers that link to SQLServer and Oracle are good quality and can handle complex primary keys, but I've used junky drivers that link to obscure databases and they couldn't handle complex things like subqueries, union queries, etc, even though you could do those things in the database itself; the driver was only written to handle basic select/insert/update/deletes and that was it.
Related
I have run into the problem addressed here (cannot add view to the edmx) multiple times over the years. Following the directions normally works. This past week, none of the suggested fixes are working. I'm working a port of data that's a mix of Access and SQL Server. I had a couple problems in the past related to the project that were sorted out by all the suggestions in the other question.
Here's what I had: a view that pulled from data created as a batch from Access tables once a week. That's as icky as it sounds. This information consists of a name and a simple integer. From there, I have two other views dependent on it. (This is where my problem could be: view within view.)
Next, I created a view that pulls from live SQL data and produces the same results consisting of the same name and a count. Both static and live views show that the name is not null and the count is nullable.
However, the secondary views of the static data show not-null for the name. This is fine. It let's EDMX create an entry for it. But, even though I create a views by scripting the working views to a window (and then pointing the view at the live data view), that view has decided that the names are nullable. Then EDMX can't decide what to do with it.
I tried all the standard solutions, but even generating a new identity field as part of the view still produces all nullable columns. The thing that drove me over the edge is that I finally said, "let me look at the view in the designer." I did. It looked normal. I changed nothing, but I did hit a Ctrl-S to save it. I refreshed the view and suddenly SSMS shows that the not-null columns are all now nullable. I got this result on two databases: my local test and remoting to the client's computer. The only thing so far that I can think to explain this is that SQL Server itself changed some subtle rules on views that use views.
For now, I'm going to make stored procedures, but it would sure be nice to know why this has stopped working for me.
I have recently been allotted development tasks at my job after a couple of years providing customer training/service/support (Yay, long run paying off!) I pointed out to my supervisor and was agreed with that we need to add a couple of tables to implement a new feature in order to stay consistent in the way that our front-side application handles the information in the database.
Currently, information is stored all together in one table until it is approved by an end user to be permanently added to the database. It is possible for the information to be one of three types - Two of the three are special case scenarios that require a second level of finalization from an end user before being put into their final location. For these two that require the second level of finalization, all of the other bits and pieces of information that supplement the primary information are stored in separate tables from the primary piece.
My question is this - These secondary tables where the information temporarily resides before being finalized are basically all foreign keys. I was looking at creating the new set of tables from the existing initial tables - Is there a way during that creation for the new secondary table to inherit the constraints that are coming with the initial table columns?
While both of these particular tables are going to be small ones and I don't mind manually creating the script to add the constraints after the creation of the table, it seems like this would be valuable information to know in the future. I've looked through stack overflow, but all questions that are remotely similar are from a different version of SQL.
Additionally, this would have to work all the way back through SQL Server 2008, as we have not stopped supporting 2008 yet.
If you go into Management Studio, right click on the table and go to "Script Table as >" Then "Create to >" . That will add all the constraints.
I have a database and for the sake of simplicity, lets say it has two tables. One is Employee and the other is EmployeeType. In the Database diagram i am trying to build a relationship of the two tables but it gives me the following error....
'EmployeeType (HumanResources)' table saved successfully
'Employee (HumanResources)' table
- Unable to create relationship 'FK_Employee_EmployeeType'.
The ALTER TABLE statement conflicted with the FOREIGN KEY constraint "FK_Employee_EmployeeType". The conflict occurred in database "TheDB", table "HumanResources.EmployeeType", column 'iID'.
I don't know what is wrong with it. please help...
Ouch, so many downvotes. At least he bothered to post the error message. As Daniel A. White said above, you likely already have the foreign key you're trying to make. Your tag says you're using SQL Server 2008, so I'm going to assume you Microsoft SQL Server Management Studio. If that is the case, one mistake I used to make (and sometimes still do!), is I go to create a new relationship by right-clicking any of the columns in the Design view of the table I want to make a foreign key, and hit Relationships. In the Foreign Key Relationships menu that appears, I hit "Add" at the bottom, and then expand the "Tables and Columns Specification" section. Then I hit the "..." next to "Tables and Columns Specification," which lets you choose what columns you want to relate.
Now the problem here that I sometimes run into is, if you don't finalize this relationship right here, you're setting yourself up for situations like this. The reason is, is that when you hit "Add" a few steps back, you already created a foreign key on this table. Even if you cancel out and close everything, the table retains that foreign key. If you experimented around with this, you may have already accidentally created the relationship, you just didn't know it then.
I realized how often I made this mistake when I first started, because I looked back at my very first project a year after I began working with SQL Server 2008, and the Foreign Key Relationships are funny, because I have a ton of foreign key entries pointing to no where in every table, where I obviously was just experimenting as I was learning.
Another thing, just to cover some more bases here, is that you mentioned you were doing this in the Database Diagram view. Don't think there's anything wrong with that, but I've found that sometimes doing things via the GUI, it can be kind of flakey. By that, what I mean is, sometimes I will want to make a really small and minor change, but the GUI will tell me that I can't do that kind of change after the table has been made. But then if I just do exactly what I want to do via a typed out query, it runs just fine.
The ultimate test to try to see if you have your desired functionality is to simply try putting in a record that would violate the foreign key restraint. If it goes through, then the relationship isn't there or it's not set up properly. If it fails, then you know you've already got what you want.
I think you got some downvotes because this isn't a very complicated problem/should usually be easily solvable on your own, especially with Google. Since it's not, but you bothered to post anyway, I'm assuming you're somewhat new to this, so I just wanted to throw out my advice as a fellow newbie. Don't let the downvotes get you down, just maybe next time ask a little more concrete question other than "what's wrong?" For instance, "This error seems to be telling me the key already exists. Can anyone tell me how to check and see what relationships already exist? I don't remember making this relationship, how could this have happened?" etc.
A simple answer: you have data in your tables which would break this relationship, so you cannot create the relationship.
In this case, check the Employee table and look for rows where the id for EmployeeType (EmployeeTypeId?) is either NULL or illegal (not to be found in the EmployeeType table). Fix these rows and the relationship will save OK.
Every now and then when I'm browsing data in a database, I get tired of writing ad-hoc queries to join in the various tables I want to see, and I go looking for an app that will:
Allow me to follow foreign key relationships
Automatically display tables in a tree-like format based on relationships
Compose views by automatically joining on foreign keys
I know this can be done because I wrote (and lost) such an app many years ago, but I can't seem to find anything out there. The closest I've seen is generated "scaffolding" such as RoR and MS Dynamic Data.
You could try the "Data Browser" included in the tool Jailer (Screenshots). It allows you to navigate through the database based on relationships.
The site I am working on as a student will be redesigned and released in the near future and I have been assigned the task of manually searching through every table in the DB the site uses to find tables we can consider for deletion. I'm doing the search through every HTML files source code in dreamweaver but I was hoping there is an automated way to check my work. Does anyone have any suggestions as to how this is done in the business world?
If you search through the code, you may find SQL that is never used, because the users never choose those options in the application.
Instead, I would suggest that you turn on auditing on the database and log what SQL is actually used. For example in Oracle you would do it like this. Other major database servers have similar capabilities.
From the log data you can identify not only what tables are being used, but their frequency of use. If there are any tables in the schema that do not show up during a week of auditing, or show up only rarely, then you could investigate this in the code using text search tools.
Once you have candidate tables to remove from the database, and approval from your manager, then don't just drop the tables, create them again as an empty table, or put one dummy record in the table with mostly null values (or zero or blank) in the fields, except for name and descriptive fields where you can put something like "DELETED" "Report error DELE to support center", etc. That way, the application won't fail with a hard error, and you have a chance at finding out what users are doing when they end up with these unused tables.
Reverse engineer the DB (Visio, Toad, etc...), document the structure and ask designers of the new site what they need -- then refactor.
I would start by combing through the HTML source for keywords:
SELECT
INSERT
UPDATE
DELETE
...using grep/etc. None of these are HTML entities, and you can't reliably use table names because you could be dealing with views (assuming any exist in the system). Then you have to pour over the statements themselves to determine what is being used.
If [hopefully] functions and/or stored procedures were used in the system, most DBs have a reference feature to check for dependencies.
This would be a good time to create a Design Document on a screen by screen basis, listing the attributes on screen & where the value(s) come from in the database at the table.column level.
Compile your list of tables used, and compare to what's actually in the database.
If the table names are specified in the HTML source (and if that's the only place they are ever specified!), you can do a Search in Files for the name of each table in the DB. If there are a lot of tables, consider using a tool like grep and creating a script that runs grep against the source code base (HTML files plus any others that can reference the table by name) for each table name.
Having said that, I would still follow Damir's advice and take a list of deletion candidates to the data designers for validation.
I'm guessing you don't have any tests in place around the data access or the UI, so there's no way to verify what is and isn't used. Provided that the data access is consistent, scripting will be your best bet. Have it search out the tables/views/stored procedures that are being called and dump those to a file to analyze further. That will at least give you a list of everything that is actually called from some place. As for if those pages are actually used anywhere, that's another story.
Once you have the list of the database elements that are being called, compare that with a list of the user-defined elements that are in the database. That will give you the ones that could potentially be deleted.
All that being said, if the site is being redesigned then a fresh database schema may actually be a better approach. It's usually less intensive to start fresh and import the old data than it is to find dead tables and fields.