I was hoping someone would be able to help with why one of my Access 2007 databases seems to be rather randomly assigning an autonumber as an ID.
I understand that it's a unique number assigned automatically by access.
My question is why has access jumped from 4 to over 50,000,000 when no data has been inserted since record 4 as below?
Related
I have an issue/problem that I'm looking for a solution for. If I find a solution for this, it could fix two issues I'm facing in a database tool I'm creating for my school's admin office.
The gist of it is, I'm looking for a way in Access 365 (or Access 2019) either through a form/query/vba... to limit data to not have duplicates. Now, of course I know that you can set the field in your table to not have duplicates. But, here is the thing, I wouldn't mind a duplicate in that column in certain cases.
So, let me explain the issue/problem by giving an example.
Image that you have two tables. One table is filled with the name of a school bus and the yearly price that the parents have to pay for it. Another table has all the stops that the school busses take.
Now, here comes the problem. I would love to have a system where I can let the user decide the order of those stops.
What I'm currently doing is, I let the user fill in a number. In another column, I have a calculated field that adds the primary key of the schoolbus table "." the number of the order.
So, that would look like this for the first school bus and the first five stops.
1.1, 1.2, 1.3, 1.4, 1.5
And I have a duplicate control that column. Since that way, I can make sure that it doesn't block the number 1 for the next bus.
Something that might work as well, if that's possible in access is that for each school bus you create, you add a column in the stops table to check for duplicates. But how do you make sure then to filter which stops belongs to which schoolbus?
I hope my issue is a bit clear. If it's not, feel free to ask.
I have a similar style problem in another part of the tool with a book fair system.
Where you have an order table where the order number, the student number, the creation and pickup dates are stored. It also has a field to lock the form to avoid any edits for the bookkeeping folks. I also have an orderline form where all the actual bought books are stored. Now, I would love it if a system exists to avoid users adding the same book twice on an order in the orderline table since I do have an amount column for that. So, in a way, it's almost similar to the above described problem.
My company uses an SQL Server database, with Access as a front end. One of the biggest tables on the server is called tbl_Contacts. The primary key, "ContactID" was setup as an auto-incrementing "int" data type. Turns out yesterday afternoon, the limits of the "int" type ran out, and no new contacts could be added to the table.
At first I tried just updating the data type to "bigint", but then Access couldn't recognize the data type and showed "Deleted" for all the fields in the Contacts table.
I read a bunch of different articles and realized that Access 2010 cannot understand the bigint data type, and that I would need to cast the field to a different type that Access could understand.
I ended up making a View of tbl_Contacts and used this SQL to modify the ContactID field, including all the other fields in the table as is.
CAST(ContactID AS Decimal(15, 0)) AS ContactID
I then renamed the old linked table in Access to tbl_Contacts_OLD, added the new ContactsView table into Access with an ODBC connection, and renamed the View to "tbl_Contacts".
I thought everything was working, because I could add new records to the table again, but it turns out some things are still not working.
The only thing I can imagine is that other tables in my database are expecting "ContactID" to be a "Long Integer", and they aren't liking it being a "Decimal".
When I try to use a form that adds data to a table "tbl_CallLog", which links to "tbl_Contacts", I get this error.
Run-time error '3101'
The MS Access database engine cannot find a record in the table 'tbl_Contacts' with key matching field(s) 'ContactID'
Is there another data type I should be casting to that Access 2010 can recognize and use? Is there maybe a step I still need to do, perhaps casting the decimal value to yet another data type within Access?
Do I need to convert the data type on all other tables that reference the original Contacts table so they're linked fields are now decimal data types?
BigInt can be understood only by Access 2016.
The data types for a record id should be either Long or GUID. Long is by far the most commonly used.
So this isn't the best solution in the world, but I finally got my problem fixed doing the following.
My tbl_Contacts table only has 99k records in it, but due to various reasons, and the table being 20 years old, the IDENTITY SEED was at 2+ billion, the limits of the "int" datatype. I looked through the IDs and found a gap of 120k numbers, so I used this query to reset my seed value.
DBCC CHECKIDENT ('[tbl_Contacts]', RESEED, -92801);
GO
I've created several test contacts now, and the first one had the ID number -92800.
This should hold me until I can get a new CRM system in place in the middle part of the year.
Thanks for the comments, Gustav.
I'm looking for a way to protect the identity of people in my SQL database.
The database has rows containing an unique hash that represents a person and personal data about this person. The idea is that certain personal/medical data is hashed so anyone can add/edit/delete columns and anyone can request columns but can never request the unique hashes.
Representation database:
Joe+1994 --> q4y23z
|Hash| |Age| |Height| |Smoker|
---------------------------------
q4y23z 21 200cm 0
r8h32l 21 100cm 1
9itj5b 21 100cm 1
This all works fine but the database is very small at this moment. If someone knows that I am represented in this database and knows that I for instance am a non-smoker and am 2m tall then this person will discover my identity and other personal data. Is there any known technique to limit the access to certain columns until the amount of rows is large enough to provide anonymity?
Sincerely,
Joe
Currently I'm performing a migration from a microsoft access database to an SQL Express 2010 database.
Basically, I have an Access application that searches a customer database. The access app is developed in 2 parts. An access front end on each client called application.mdb and a data backend on a windows 2008 server called data.mdb. The application.mdb has 3 linked tables to data.mdb. which holds customers and contracts and items. The customer table relates to the contracts table (one to many) and the contracts table relates to the items table (one to many)
I imported the tables from the data.mdb into the sql tables by the same name and created the same relationships and configured them to cascade. I then created an obdc connection on the clients and updated the 3 linked tables in application.mdb to point to the tables on the sql server.
I start the application and everything seemed to work great, I can see all the data perfectly and the performance increase was well worth the effort.
Then I found a problem, when I add a new customer to the database it autonumbers the customer table and the contracts table but not the items table.... Thus if I attempt to alters any of the items in the items table for new customers I can not. I get the following error "cannot add record(s); primary key for table "items" not in recordset" which makes sense because SQL had not autonumbered the items table.
I can't understand why....
Any help would be greatly appreciated.
Well, just manually adding record direct in the items view should tell you if the autonumber is working. You MUST get the autonumber working when you edit + use in direct table view.
As always these kinds of issues comes down to the details. One thing that's different when using a SQL based backend compared for access applications is the generation of auto numbers (primary key) does not occur on server based systems until record is actually saved. When working with the jet based back end, the auto number is available the instant the record is dirtied.
So I would check if you have some type of code or event running in the application that is attempting to use as primary key value before the record been actually saved.
Usually access does a pretty good job. For example when you build a form in access, and then have a sub form in access to edit child records (and a child table), then as a rule when the focus switches from a main form to a sub form, access will force a save of the main record. This thus means the primary key (auto number column) is now available for correct functioning of the relationship. Access can and will use this PK value and insert this value into the foreign key value column in this child table for you.
However access will only do above for you WHEN you correctly set up the link master and link child settings in the sub form control. As a general rule when building forms in regular access, Access can detect the settings required and insert the correct values into the link master and link child settings for you. However, the detection of the FK column will not occur with linked tables.
So when you use SQL server, you have to edit and set these values manually in the sub form control. So I would check your link master and link child settings in the sub form you're using to edit this data, and ensure that the correct values are set. If this is VBA code, then ensure the record is actually saved before attempt to use and grab a PK value.
I should point out that even in non SQL server based applications, it is the setting up of the link master + child settings in the sub form that allows access to setup and maintain this foreign key value for you. So access is always had the ability to insert these values for you, and it'll do so with you about having to write any code at all. So during the editing process to insert and maintain these values Access does all of the work for you (so it's not the data engine that inserts these FK values for you, but the user interface or in some cases code you write)
So access will not setup and insert these correct values unless you set up the link master + child settings in that sub form control.
I would simply check if your link master and child master settings are correct in any sub form control you are using here.
This sounds like a stupid answer but check the Items table to be sure that auto-numbering is turned on.
One of the things I would suggest whenever you migrate a Jet/ACE database to SQL Server is to thoroughly review the database design, e.g.: the implementation of keys and constraints, choice of data types, choice of indexes, etc. Jet/ACE is a very different thing to most SQL DBMSs so you shouldn't assume that a database design that worked well for Jet/ACE is automatically suitable for a SQL DBMS. Upsizing wizards won't always identify every possible issue.
In SQL Server the nearest equivalent of an "auto-number" is the IDENTITY property. Check to be sure which columns are IDENTITY in your tables and create an IDENTITY column if you need one.
I am working on a VB.net (VS-2010, Win XP Pro 2 SP3), Employee Management Project. I need to keep track of Employee Leave Attendance and also each Equipment assigned to an Employee. How can I achieve this using SQLlite.
It will be very useful if you could provide me with examples as I am completely new to the field of SQL and VB.net
I think this can be done with two tables where one has the primary key while the other has a foreign key, but I am not sure. Also how many tables will I need for storing data in Leave and Equipment Form.
I went through other questions but I was unable to figure out a solution for my problem.
(Sorry, I cannot provide with images as this site prevents me from posting images without 10 reps)
Most problems are only as complex, and as simple as you make them. Out of habbit, nearly all tables end up with a unique ID field. There are exceptions, which I will call "link" tables, eg, ones that provide connection details between two data tables.
Now, in your senario
You would need a "holiday" table, where each row will contain the employee unique ID and either a start/finish date, eg, if they take half a day, it needs to be visible, or, just a year and value, eg in 2011, I booked, 2 lots of 35 hours, and 1 lot of 4 hours eg, Ive taken 2 weeks and half a day.
For the equipment, you would need a data table, since an item can only got to 1 employee, it depends if you're going to use this for booking or not, but if its just like a library, eg I currently have a loaner laptop, then you can just have an employee field in the equipment table. If you need a booking system, then you would require link tables and more complex.
Best way to work out your tables is to try and group your data, and then write the items on peices of paper and see how you as a human do it. After a while you end up able to do so in your head.