If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Upsizing of database
I created one bibliographic database using ms access 2003. I think it will
incease gradually and exceed the limit of desktop database i.e. 2 GB. What should I do? I created an user interface which includes 3500 queries, 90 forms with necessary visual basic codes. The number of tables is 5. Now it is of 70 mb. Please give me the suggestions as early as possible. With regards, -- nandini |
#2
|
|||
|
|||
Upsizing of database
well, you've obviously done a lot of design work, so i'd start by compacting
the database, if you haven't already been doing that regularly during development. then i might review my tables' fields to make sure the data types are optimized. for instance, if you're using Double field size for number fields that will hold only whole numbers, you can save space by changing the field size to Long Integer. and review the "whole number" field size assignments too. if you have a number field where the highest value will *never* be more than 255, but the field size is Long Integer or Integer, there again you can save space by changing the field size to Byte. ditto values that will never be larger than Integer field size, make sure the field size is Integer, not Long Integer. NOTE: back up your database before changing data types or field sizes, just to be safe. next, i'd split the database, because you've got a fair amount of space eaten up with the user interface objects (everything except the tables). also, if your design incorporates "archive" tables to hold obsolete data, you can consider moving those tables into a separate database. since your frontend (user interface) is already separate from the backend (tables), it doesn't matter if the linked tables in the frontend are coming from one backend database, or multiple backend databases. having done all that, and compacting as you go, you're starting with as small a backend database as possible. if you regularly add/delete/edit records, you should regularly compact the db, to keep it as small as possible. now, having said all that, 70 mb is pretty small, as compared to 2 GB. depending on just how "gradually" you expect the size of the data file to increase, it may be quite some time before you have to consider upsizing for space purposes. hth "Nandini" wrote in message ... I created one bibliographic database using ms access 2003. I think it will incease gradually and exceed the limit of desktop database i.e. 2 GB. What should I do? I created an user interface which includes 3500 queries, 90 forms with necessary visual basic codes. The number of tables is 5. Now it is of 70 mb. Please give me the suggestions as early as possible. With regards, -- nandini |
#3
|
|||
|
|||
Upsizing of database
Thanks for your suggestion.
I regularly go through the tool of compacting repairing database after editing or updating. As this is a bibliogrphic database of a library, so it is expected to be increasing gradually and once it will reach at the end point of the limit. I am interested on your suggestion of splitting of database. Is it possible to retrieve data from multiple backend databases from the same user interface at the front end? I have not any detailed knowledge about this. Please help me much more. With best regards, -- nandini "tina" wrote: well, you've obviously done a lot of design work, so i'd start by compacting the database, if you haven't already been doing that regularly during development. then i might review my tables' fields to make sure the data types are optimized. for instance, if you're using Double field size for number fields that will hold only whole numbers, you can save space by changing the field size to Long Integer. and review the "whole number" field size assignments too. if you have a number field where the highest value will *never* be more than 255, but the field size is Long Integer or Integer, there again you can save space by changing the field size to Byte. ditto values that will never be larger than Integer field size, make sure the field size is Integer, not Long Integer. NOTE: back up your database before changing data types or field sizes, just to be safe. next, i'd split the database, because you've got a fair amount of space eaten up with the user interface objects (everything except the tables). also, if your design incorporates "archive" tables to hold obsolete data, you can consider moving those tables into a separate database. since your frontend (user interface) is already separate from the backend (tables), it doesn't matter if the linked tables in the frontend are coming from one backend database, or multiple backend databases. having done all that, and compacting as you go, you're starting with as small a backend database as possible. if you regularly add/delete/edit records, you should regularly compact the db, to keep it as small as possible. now, having said all that, 70 mb is pretty small, as compared to 2 GB. depending on just how "gradually" you expect the size of the data file to increase, it may be quite some time before you have to consider upsizing for space purposes. hth "Nandini" wrote in message ... I created one bibliographic database using ms access 2003. I think it will incease gradually and exceed the limit of desktop database i.e. 2 GB. What should I do? I created an user interface which includes 3500 queries, 90 forms with necessary visual basic codes. The number of tables is 5. Now it is of 70 mb. Please give me the suggestions as early as possible. With regards, -- nandini |
#4
|
|||
|
|||
Upsizing of database
I am interested on your suggestion of splitting of database. Is it
possible to retrieve data from multiple backend databases from the same user interface at the front end? yes. i'm currently using a working database in my job that uses linked tables from 11 different backend databases, plus several linked text files. there are loads of information on the internet about splitting an Access application into frontend (FE) and backend (BE) databases, including in these newsgroups. just google the subject. hth "Nandini" wrote in message ... Thanks for your suggestion. I regularly go through the tool of compacting repairing database after editing or updating. As this is a bibliogrphic database of a library, so it is expected to be increasing gradually and once it will reach at the end point of the limit. I am interested on your suggestion of splitting of database. Is it possible to retrieve data from multiple backend databases from the same user interface at the front end? I have not any detailed knowledge about this. Please help me much more. With best regards, -- nandini "tina" wrote: well, you've obviously done a lot of design work, so i'd start by compacting the database, if you haven't already been doing that regularly during development. then i might review my tables' fields to make sure the data types are optimized. for instance, if you're using Double field size for number fields that will hold only whole numbers, you can save space by changing the field size to Long Integer. and review the "whole number" field size assignments too. if you have a number field where the highest value will *never* be more than 255, but the field size is Long Integer or Integer, there again you can save space by changing the field size to Byte. ditto values that will never be larger than Integer field size, make sure the field size is Integer, not Long Integer. NOTE: back up your database before changing data types or field sizes, just to be safe. next, i'd split the database, because you've got a fair amount of space eaten up with the user interface objects (everything except the tables). also, if your design incorporates "archive" tables to hold obsolete data, you can consider moving those tables into a separate database. since your frontend (user interface) is already separate from the backend (tables), it doesn't matter if the linked tables in the frontend are coming from one backend database, or multiple backend databases. having done all that, and compacting as you go, you're starting with as small a backend database as possible. if you regularly add/delete/edit records, you should regularly compact the db, to keep it as small as possible. now, having said all that, 70 mb is pretty small, as compared to 2 GB. depending on just how "gradually" you expect the size of the data file to increase, it may be quite some time before you have to consider upsizing for space purposes. hth "Nandini" wrote in message ... I created one bibliographic database using ms access 2003. I think it will incease gradually and exceed the limit of desktop database i.e. 2 GB. What should I do? I created an user interface which includes 3500 queries, 90 forms with necessary visual basic codes. The number of tables is 5. Now it is of 70 mb. Please give me the suggestions as early as possible. With regards, -- nandini |
#5
|
|||
|
|||
Upsizing of database
On Sun, 15 Feb 2009 21:10:01 -0800, Nandini
wrote: I created one bibliographic database using ms access 2003. I think it will incease gradually and exceed the limit of desktop database i.e. 2 GB. What should I do? I created an user interface which includes 3500 queries, 90 forms with necessary visual basic codes. The number of tables is 5. Now it is of 70 mb. Please give me the suggestions as early as possible. With regards, How long has it taken to get to 0.07 GByte? How soon (realistically) do you expect to exceed 2.0 GByte? Are you perhaps borrowing trouble? If so, be aware that the interest rate is ruinous and you usually don't get to keep the trouble anyhow... g -- John W. Vinson [MVP] |
Thread Tools | |
Display Modes | |
|
|