| Author |
 Topic  |
|
|
riseoff
Starting Member
5 Posts |
 Posted - 03 Sep 2010 : 19:39:11
|
Hi everybody,
My question is about the size that the database can grow, i'm told that access db size limit is more or less 2GB.
I once stopped using a competitor's program because of this.
Does XMM solutions have also this limitation?
Thanks for reading! |
|
|
Alessio Viti
Forum Admin
Italy
9171 Posts |
|
|
riseoff
Starting Member
5 Posts |
Posted - 03 Sep 2010 : 21:52:39
|
Hi Ale,
Was just a general question, i was excited after reading your mail with a possible future eXtreme Book Manager (the ability to fetch data from chained scripts is unique to your programs).
I'm interested in a solution that can handle unlimited entries and without database size limited. I was a former user of BookCat until i reached this limitation (a limitation of this type of databases), at that time i got catalogued about 100.000 items (covers linked outside the database).
Create multiple databases is not an option.
Hope i made myself clear, i'm not fluent in writing english.
Regards |
Edited by - riseoff on 03 Sep 2010 21:53:30 |
 |
|
|
Alessio Viti
Forum Admin
Italy
9171 Posts |
Posted - 04 Sep 2010 : 08:18:36
|
Hi,
I don't think it will be a problem, but to be honest I haven't test the database for 100.000 titles.
For sure I will make test comings weeks, I am curious about this 
Before Christmas I have plan to release software for Book and Music.
Thank you,
Ale |
http://www.facebook.com/pages/eXtreme-Movie-Manager/47220214342?ref=mf
 |
|
|
|
riseoff
Starting Member
5 Posts |
Posted - 04 Sep 2010 : 10:57:53
|
Thanks a lot for testing it, if you need me to help you in any test just send me a message.
Have in mind that the limitation is not the number of titles (i think) but the database size (max 2GB), you can view specifications here:
http://www.databasedev.co.uk/access_specifications.html
I agree that for regular/home cataloguers this is not an issue, but for hard-core ones this is a no-go path.
Thanks again for reading and looking forward to hearing from you once you have done the testing.
Regards
BTW, nowadays the colletion has grown more than 400k items, so you can get an idea of the size it can get. |
|
|
|
Alessio Viti
Forum Admin
Italy
9171 Posts |
|
|
riseoff
Starting Member
5 Posts |
Posted - 04 Sep 2010 : 12:41:00
|
Yep the db is filled with info, but the idea would be to import just a pool of ISBNs (10-13)/ ASINs / Dummy numbers for items without ISBNs, and then let XBM do its magic.
|
|
|
|
Prinz
Senior Member
Germany
1522 Posts |
Posted - 04 Sep 2010 : 13:32:52
|
Yes Access has a limit of 2GB per File. But that can be worked around with split databases (backend).
http://www.fmsinc.com/MicrosoftAccess/DatabaseSplitter/Index.html
But this still has the limitation per Database File. For such big Databases is Access not the right format. Big Databases should be something like MySQL. |
|
|
|
Mawu
Senior Member
Germany
1039 Posts |
Posted - 04 Sep 2010 : 21:30:03
|
Especially for a music database I would recommend to switch from Access to SQLite.
Bye Byte and Happy Coding
Mawu |
www.schlemmerkino.de - Die Nr.1 für filmische Leckereien |
|
|
|
Alessio Viti
Forum Admin
Italy
9171 Posts |
|
|
ComZiz
Junior Member
Turkey
282 Posts |
Posted - 22 Sep 2010 : 21:05:49
|
@Alessio
If you ever plan to change the database type in the future, please keep an option to keep it access, as I occasionally open my database in Office to work out some repeated jobs...But Sql, I can't... |
|
|
|
Alessio Viti
Forum Admin
Italy
9171 Posts |
|
|
Mawu
Senior Member
Germany
1039 Posts |
Posted - 24 Sep 2010 : 09:03:16
|
Hi Alessio,
I think for XMM you don't really need to switch to an sql database. But for a music manager there are too many limitations for big collections (>20000 mp3). And there are also possibilities to manage sql databases, e.g. for SQLite there is a Firefox plugin (https://addons.mozilla.org/de/firefox/addon/5817/). Maybe for an extreme Music Manager you can provide more than one database option (like in Helium Music Manager).
Bye byte and Happy Coding
Mawu |
www.schlemmerkino.de - Die Nr.1 für filmische Leckereien |
|
|
|
Alessio Viti
Forum Admin
Italy
9171 Posts |
|
|
riseoff
Starting Member
5 Posts |
Posted - 25 Sep 2010 : 09:29:45
|
back from holidays :)
@ComZiz
That's true, i heavily used access to import/update thousands of fields from excel or other sources into BookCat database.
But what does happen when you reach the size limit?
This very limitation will make medium-big collectors, organizations, local libraries look to other places. Implementation of a solution like the one Mawu proposed, sqlite or perhaps a tool to choose which database you want to use at database creation time will solve the issue, add to that the multiple/user programmable download of data from any source, a good loan manager, lots of custom data fields, and the other thingies XManagers have and you will be in front of a yes-yes solution for almost every segment of possible customers.
@Alessio
Thanks for getting involved or at least trying what Mawu is suggesting for XMM and XBM.
Regards |
|
|
|
7bpm
Starting Member
12 Posts |
Posted - 22 Dec 2010 : 13:41:03
|
Either way it'll be a lot better to have the option, even in Movie Manager, to cennet either on an Access db or a SQL server.
Any further news on this one Allesio? |
|
|
|
magician62
Starting Member
49 Posts |
Posted - 12 Jun 2011 : 20:42:39
|
While this is an old subject, the following may give more undertanding of teh size limitations. The way to obtain the maximum possible storage is as mentioned befored to have a frontend databace that links to back end database's
The maximum storage is achieved by placing just 1 table in each database So for example 50 tables in 50 databases each could be 2GB in size. The problem is one database/table is obviously going to hit the 2GB limit first, when that happens your at your limit. The second problem you get is it can become very slow. |
|
|
|
katleeh
Starting Member
USA
12 Posts |
Posted - 23 Jun 2011 : 23:29:23
|
Okay this might be a more workable solution or it might not. What about putting the series episodes, actors, and things like that in seperate database files? The slow down would be minimal and to speed things up you'd have a data file that would load to memory with relevant information? This seems like the only way you'll be able to get around the file size problem unless you design your own database format which would also work. By splitting the files up, at least you minimize the problem.
- katleeh |
Edited by - katleeh on 24 Jun 2011 00:11:30 |
|
|
|
Alessio Viti
Forum Admin
Italy
9171 Posts |
|
| |
Topic |
|
Database limitation