My Assistant
![]() ![]() |
|
|
Feb 13 2011, 09:32 AM
Post
#1
|
|
|
New Member Posts: 8 |
Hi,
I am required to remove all old data in my old database (2007 version) for my new construction project. I can start inputing the data from primary key 1. But, it is difficult to find out the function. I tried for few hours.... today thz for your help in advance. |
|
|
|
Feb 13 2011, 09:41 AM
Post
#2
|
|
|
Utterly Yorkshire and Forum/Wiki Editor Posts: 15,895 From: Devon UK |
Hi
If you open each table and press Ctl + A to select all records in the table, you can just press the Delete key. If you have related tables with Referential Integrity set you'll need to delete the child records before the parent records, but you'll get a message telling you that you can't delete records because etc etc if that's the case. Once all the records are deleted, Compact and Repair the db (Office Button, Manage) and all Autonumbers will start again from 1 |
|
|
|
Feb 13 2011, 10:39 AM
Post
#3
|
|
|
Access Wiki and Forums Moderator Posts: 48,642 From: SoCal, USA |
Hi,
(IMG:style_emoticons/default/welcome2UA.gif) You may also check out Bob's website for a utility called "Database Reset Tool." Hope that helps... |
|
|
|
Feb 14 2011, 12:16 PM
Post
#4
|
|
|
Utterly Crispy UA Forum Administrator Posts: 7,119 From: Edmonton,Alberta,Canada |
If you are just looking to delete the data from tables here is a function that will do that. It will not effect the system tables generated by Access. You still have to do a manual compact and repair after running function before entering new data. This only works for non linked tables.
Bobs utility maybe more what your looking for. CODE Function EmptyTables()
Dim tblCurr As TableDef, dbCurr As Database Dim tblName As String Set dbCurr = CurrentDb For Each tblCurr In dbCurr.TableDefs If Left(tblCurr.Name, 4) = "MSys" Then ' Do Noting Else tblName = tblCurr.Name dbCurr.Execute "DELETE * FROM " & tblName End If Next MsgBox ("You must Compact and Repair this database before you start entering new Data") End Function |
|
|
|
Feb 14 2011, 01:08 PM
Post
#5
|
|
|
UtterAccess VIP Posts: 8,192 From: Pacific NorthWet |
Different folks have different meanings for the term "remove". Some folks think that means "tear 'em out and physically get rid of them". But another interpretation is "make them so I can't see them ... until I want to see them".
Are you (or someone else) ever likely to need or want to see those old records, for historical purposes/comparisons, or for ... giggles, or because I just remembered something and want to check ...? If the answer is "yes", then consider that second interpretation above, and make those records disappear without removing them. If the answer is anything else (e.g., "heck no! never!"), use the second interpretation and make those records disappear without removing them. I've run into too many situations where the owners/users are insistent that they would NEVER need the data ... until they need the data! Best of luck! |
|
|
|
Feb 14 2011, 01:12 PM
Post
#6
|
|
|
UtterAccess VIP Posts: 2,336 From: West Michigan |
The only absolute (never/always) I believe about databases is the inevitability of change. Things that will NEVER change, *always* do; and things that will ALWAYS be, *never* are.
|
|
|
|
Feb 14 2011, 02:01 PM
Post
#7
|
|
|
Utterly Crispy UA Forum Administrator Posts: 7,119 From: Edmonton,Alberta,Canada |
Hi Jeff I agree with you you should not delete the data.
However some people just copy the database at years end and rename it with the year added to the name. The function I submitted would give them a clean database to start with after the manual compact and repair. A better solution is to archive the data and have the ability to restore when needed if size is a problem, if not as you suggested just not make it visible. |
|
|
|
Feb 14 2011, 02:08 PM
Post
#8
|
|
|
UtterAccess VIP Posts: 8,192 From: Pacific NorthWet |
Glen
That certainly works for some folks... until they want to compare "last year's" numbers with the current year. Then it gets sticky trying to connect (let alone find!) the older data. Much easier, in the long run, to have all the data in one place, and only look at the "current" data... (the voice of painful experience!). |
|
|
|
Feb 14 2011, 03:03 PM
Post
#9
|
|
|
Utterly Crispy UA Forum Administrator Posts: 7,119 From: Edmonton,Alberta,Canada |
QUOTE Much easier, in the long run, to have all the data in one place, and only look at the "current" data... (the voice of painful experience!). I hear you on that one but database size can become a problem if not split which reinforces the need to split every database ... (IMG:style_emoticons/default/thumbup.gif) |
|
|
|
Feb 14 2011, 07:42 PM
Post
#10
|
|
|
UtterAccess VIP Posts: 8,192 From: Pacific NorthWet |
I've run across one user who'd db was facing a size crisis which (sorta) warranted using multiple dbs. He was collecting stock quotes, thousands of records per day, reasonably expecting to outgrow Access' size limit.
Other than that, until the OP describes the actual record size and growth expectations, I'll still stick with a single (back-end) db file. |
|
|
|
Feb 23 2011, 09:24 AM
Post
#11
|
|
|
New Member Posts: 8 |
Recently, I am busy with my new project and so i havent come back to this site.
anyway, thz a lot. |
|
|
|
Feb 23 2011, 10:19 AM
Post
#12
|
|
|
Utterly Crispy UA Forum Administrator Posts: 7,119 From: Edmonton,Alberta,Canada |
|
|
|
|
![]() ![]() |
|
Go to Top · Lo-Fi Version | Time is now: 19th June 2013 - 09:41 PM |