So I have this project on access 2003. I am trying to create a relation diagram of the tables. I have found this webpage of Microsoft: http://office.microsoft.com/en-us/access-help/create-a-database-diagram-adp-HP003085405.aspx but I do not see any Database diagram option as I was supposed to see according to that article.
I am not even sure what they meant by Diagram window (I can see the list of tables, forms, queries and so on in a window, is that what they meant?). I have worked with DB diagram in access 2007 and 2010 but 2003 seems to be totally different.
And another question: is there any restriction in creating diagram on front-end/back-end application?
The solution to this problem was fairly simple. I just had to double click on my mdb file then hold down the shift key. That made the options visible. The rest was easy.
Sorry my question might not be clear. I saw one answer but I think that is too advanced for me to even understand.
That article is referring to what is called an ADP project. An ADP project is a specialized type of Access database that ONLY works with SQL server. Thus the article you reference would not apply to creating regular Access databases (that are not working with SQL server). Perhaps you can clear up if you are in fact using an ADP (Access Data Project). From your description it sounds like you are not.
As for the locating where you build the diagram and setup relatonahsips, it always in the back end (or the "same" database). I mean you could not have 5 different front ends link to a back each with different relationships settings. So the actually physical mdb (or accdb) file is where the relationships are setup and other systems from Excel, word or even a MS Access front end can only link to that data file – not set up relationships.
As for the diagram option missing? You should find the option under the menu option
Tools->relationships
Related
I'm currently developing a webapp to a costumer and I need to import data from their old application.
As far as I can tell, the database is dBase written with FoxPro.
I have the application exe and lots of dbf/dbb/dbi files and I can open the dbf table files thanks to the DBF Commander.
Although I can open each table and see the data, I really could use an EER diagram to understand how the tables connect to each other.
Is there any tool that could reverse engineer the database and draw the EER diagram?
Thank you for time.
Regards,
Hugo
A lot depends on whether it's just a bunch of DBF/CDX/FPT files, or whether they belong to a database container (DBC/DCT/DCX extensions). If there's no database container, i.e. 'free tables', they haven't necessarily been created by FoxPro, it could have been any of the xBase languages, like Clipper and so on.
If they are part of a database container then there may be metadata in it defining rules, triggers, relations.
Even so, you probably really need a copy of Visual FoxPro (do you have an MSDN sub maybe?). It has a built-in tool called GenDBC which will document the structure of a database if it has a database container.
There is also the Stonefield Database Toolkit which would give better tools in this regard.
Or you could use the Upsizing Wizard in Visual FoxPro to get the data into SQL Server, and from there you would have a much better choice of tools.
See whether XCase gives you what you need: http://www.xcase.com/
I cannot see design view for forms or tables in the Services template ms access 2010.
In access options/options/current database/ the check boxes (enable layout view & enable design changes for tables in Datasheet view) are both greyed out.
My question is. How can I get into the tables in design mode?
have any idea ?
Any web objects do not have a Design View. Layout view should still be accessible, though, for forms and reports. Web objects are indicated by a globe in the icon representation of the object.
For web tables, you can only change the design in the datasheet view. Go to the last column in the datasheet view to add a new column. That's the only way to change stuff around in web tables.
I do hope that helps!
Have you copied the template to a suitable location after download and chosen Unblock from Right-Click->Properties? You can also check that the file is not read-only due to other causes.
Have you tried the old shift/open deal? Hold down the shift key, double click the file and keep holding shift until the file is completely opened.
Genius
Have you tried the old shift/open deal? Hold down the shift key, double click the file and keep holding shift until the file is completely opened.
If it doesn't have to be a "Web Database" there is a way.
Create a standard Blank database.
Right click each object (Table, Query, Report) and select Export to Access
Point it to your Blank database created in Step 1.
A. You'll have the option to export the table definition with or without the data.
I admit, it is a little tedious, and possibly could be scripted to make it easier for a lot of objects. I had a small number of objects so it only took about 15 minutes.
You can also create a new blank database and import all of the tables, queries reports etc from the old database. This is a lot faster and does the job.
If it's a Web Database:
1. The tables can be viewed in design view only by exporting to a standard access Database - or creating a standard database and importing all the tables (and relationships) in one hit.
2. The other objects (macros, forms, reports, queries) can't really be exported or imported as stated by Bobort earlier. The 'web view' doesn't allow design view (forms & reports) or sql view (queries) so it is quite restricting.
I am starting to create an MSAccess database, I have no Access experience - my previous experience is with MySQL and Oracle. Initially I had some difficulty coming to terms with the fact that MSAccess usually stores both the front end application and the Jet Engine database in the same file. It's different from what I'm used to. Plus the database will be shared over a network, and it just makes more sense to split the application from the data.
After some reading, I see that it is possible to store data in one file, and then link to the application elements in another file. Every article I've come across for this deals with splitting the database into two parts, after the database has already been made, and never discusses creating split database applications from the start. Is it because that would be a bad idea? I can't really imagine why, except that I've noticed that Access does not let me keep two database files open at the same time (it automatically closes one). So I am foreseeing a need to constantly to open and re-open files if I go down that route.
There is one practical reason why you might want to start with a single database. If you start with a front and back end file, you'll have to create tables in one database, then set up the link for each table manually.
This is not a big deal, but if you're just starting the system, you can save some busywork by developing the pilot system in one file, then splitting it. My assumption is you'll probably be making a lot of changes to the data structure at the outset; your work will go smoother if you're working in one file.
It is definitely a good idea to split the database before you deploy it to production. I'm not sure why you're having problems opening 2 Access files at once; this is not a restriction of Access.
You can create the two db files separately at the outset. I do that often. I seldom need both open at the same time in the Access interface. I only open the back-end database, which houses the tables, indexes, and relationships, to modify the design of those db objects. And those types of changes are relatively infrequent; most of the development workload is for the front-end db. To modify data in the tables, you can use the table links from the front-end db.
It is not a bad idea. You can have two files open at the same time, either open another Access instance or launch by double-clicking the second file. Make sure you have created a suitable back-end design before you start on the front-end.
It is more efficient to have it all in one file while you're alone to work on it. Once the database design is finalised, then you can split the db.
Splitting the db is usefull during testing as well: it allows you to reset your data to a known state in about 5 sec, just by copying a saved version of the back-end.
I've created a database in access 2007 that needs to be used by 3 users. I'm stuck because I don't know whether to place a copy on each users' computer or to place it on their SQL server. Placing it on the server would mean one access point which is desirable for data consistency but I don't know whether I need ActiveX. Don't know how to use it either. If I place it one each computer how do I work around the master file updates? Can somebody please break it all down, I'm a NEWBIE!!
Your question seems rather confused to me. You mention a SQL Server, but you don't say your application uses SQL Server for its data storage.
Thus, I can only assume that you have a single MDB or ACCDB file with your data tables and forms and reports all in the one file.
The only proper way to distribute this app is:
split it into front end (forms/reports/etc.) with linked tables that point to the back end (data tables only).
place the back end on your file server and relink your tables to point to the new location of the back end.
give a copy of the front end to each of the 3 users, who will run it from their desktop computers. If you're concerned about distributing changes to the front end, something like Tony Toews's front-end updater is very useful.
Others have jumped in to say that you should put the data in SQL Server, but most 3-user Access apps don't need the power of SQL Server. If you're not given administrative permissions on your SQL Server, it could be quite difficult to continue to alter your application's database.
On the other hand, if your database is going to grow to 1GB or more, or if you have strict security requirements, or if the data in your database is so important as to need completely failproof backups, then SQL Server would be a reasonable data store.
For most homegrown apps, not so much.
The "best" way I've worked this out is using Linked Tables in Access to go to SQL Server (since you stated you have that..?).
Using access as a front end in this scenario isn't the best thing you can do, but with 2007, it's a bit better than if you were a few versions back. Check out this article for info on linking Access into SqlServer:
Import or link to SQL Server data
One easy way is to use the EQL Data plugin: http://eqldata.com
That way you can give a copy of the database to each user, but users can sync the database with other users whenever they want. You can also access your tables and queries on the web.
Two users wanted to share the same database, originally written in MS Access, without conflicting with one another over a single MDB file.
I moved the tables from a simple MS Access database to MySQL using its Migration Toolkit (which works well, by the way) and set up Access to link to those tables via ODBC.
So far, I've run into the following:
You can't insert/update/delete rows in a table without a primary key (no surprise there).
AutoNumber fields in MS Access must be the primary key or they'll just end up as integer columns in MySQL (natch, why wouldn't it be the PK?)
The tables were migrated to MySQL's InnoDB table type, but the Access relationships didn't become MySQL foreign key constraints.
Once the database is in use, can I expect any other issues? Particularly when both users are working in the same table?
I know this topic is not too fresh, but just some additional explanations:
If you want to use MS Access effectively, especially with bigger, multiuser databases, please do the following:
split your MDB into frontend application and backend (data only) files - you'll have two separate MDB files then.
migrate all the tables with data and structure into external database. It can be: MySQL (works very well, no database size limitations, requires some more skills as it's not MS technology, but it is a good choice in many cases - moreover you can scale your backend with more RAM and additional CPUs, so everything depends on your needs and hardware capabilities); Oracle (if you have enough money or some kind of corporate license) or Oracle 10g XE (if this is not a problem, that the database size is limited up to 4 GB and it will always use 1 GB of RAM and 1 CPU), MS SQL Server 2008 (it's a great pair to have MS Access frontend and MS SQL Server backend in all the cases, but you have to pay for license! - advantages are: close integration, both technologies are form the same vendor; MS SQL Server is very easy to maintain an effective at the same time) or Express edition (same story like with Oracle XE - almost the same limitations).
relink your MS Access frontend with backend database. If you selected MS SQL Server for the backend then it will be as easy as to use the wizard from MS Access. For MySQL - you have to use ODBC drivers (it's simple and works very good). For Oracle - please do not use the ODBC drivers from Microsoft. These from Oracle will do their work much better (you can compare the time needed to execute SQL query from MS Access to Oracle via Oracle ODBC and MS Oracle ODBC drivers). At this point you'll have solid database backend and fully functional MS Access frontend - MDB file.
compile your MDB frontend to MDE - it will give you a lot of speed. Moreover, it's the only reasonable form of distributing MS Access application to your end users.
for daily work - use MDE file with MS Access frontend. For futher MS Access frontend development use MDB file.
don't use badly written ActiveX components to enhance MS Access frontend capabilities. Better write them yourself or buy the proper ones.
don't believe into the myths that there are a lot of issues with MS Access - this is a great product which can help in may occassions. The problem is a lot of people assume it's a toy or that MS Access is generaly simple. Usually they generate a lot of errors and issues by themselves and their lack of knowledge and experience. To be successfull with MS Access it is important to understand this tool - this is the same rule, like with any other technology outhere.
I can tell you that I'm using quite advanced MS Access fronted to MySQL backend and I'm very satisfied (as a developer which is maintaining this application). My friends, the users are also satisfied as they feel very comfortable with the GUI (frontend), the speed (MySQL), they don't have any issues with records locking or database performance.
Moreover, it's important to read a lot about good practices and other people experiences. I would say that in many cases MS Access is a good solution. I know a lot of dedicated, custom made systems which started as an experiment in form of private MS Access database (MDB file) and then evolved to: splitted MS Access (MDE - frontend, MDB - backend) and finally to: MS Access frontend (MDE) and "serious" database backend (mainly MS SQL Server and MySQL). It's also important that you can always use your MS Access solution as a working prototype - you have ready to use backend in your database (MySQL - let's assume) and you can rewrite frontend to the technology of your choice (web solution? maybe desktop C# application - what you require!).
I hope I helped some of you considering the work with MS Access.
Regards,
Wawrzyn
http://dcserwis.pl
I had an application that worked likewise: an MS Access frontend to a MySQL backend. It was such a huge pain that I ended up writing a Win32 frontend instead. From the top of my head, I encountered the following problems:
Development of the ODBC link seems to have ceased long ago. There are various different versions floating around --- very confusing. The ODBC link doesn't support Unicode/UTF8, and I remember there were other issues with it as well (though some could be overcome by careful configuration).
You probably want to manually tweak your db schema to make it compatible with MS Access. I see you already found out about the needed surrogate keys (i.e., int primary keys) :-)
You should keep in mind that you may need to use pass-through queries to do more sophisticated SQL manipulations of the MySQL database.
Be careful with using lots of VBA, as that tends to corrupt your frontend file. Regularly compressing the database (using main menu, Tools | Database utilities | Compress and restore, or something like that --- I'm using the Dutch version) and making lots of backups is necessary.
Access tends to cause lots of network traffic. Like, really huge lots. I haven't been able to find a solution for that. Using a network monitor is recommended if you want to keep an eye on that!
Access insists on storing booleans as 0/-1. IMHO, 0/+1 makes more sense, and I believe it is the default way of doing things in MySQL as well. Not a huge problem, but if your checkboxes don't work, you should definitely check this.
One possible alternative would be to put the backend (with the data) on a shared drive. I remember this is well-documented, also in the help. You may want to have a look at some general advice on splitting into a frontend and a backend and code that automatically reconnects to the backend on startup; I can also send you some more sample code, or post it here.
Otherwise, you might also want to consider MS SQL. I don't have experience with that, but I presume it works together with MS Access much more nicely!
Gareth Simpson opined:
If it's only two users, then Access
should do just fine if you put the
.mdb on a shared drive.
Er, no. There is no multi-user Access application for which each user should not have a dedicated copy of the front end. That means each user should have an MDB on their workstation. Why? Because the objects in front ends do not share well (not nearly as well as Jet data tables, though there aren't any of those in this scenario using MySQL as the back end).
Gareth Simpson continued:
I believe the recommended max
concurrent users for Access is 5 but
on occasion I've pushed it past this
and never come unstuck.
No, this is completely incorrect. The theoretical limit for users of an MDB is 255. That's not realistic, of course, as once you reach about 20 users you have to program your Access app carefully to work well (though the things you need to do in an Access-to-Jet app are the same kinds of things you'd do to make any server database application efficient, e.g., retrieving the smallest usable data sets).
In this case, since each user should have an individual copy of the front-end MDB, the multi-user limits of Access/Jet are simply not relevant at all.
I know this doesn't answer your question directly, but it might be worth checking out the SQL Server 2005 migration tool for Access. I've never used the tool, but it might be worth using with SQL Server 2005 Express Edition to see if there are the same issues as you had with MySQL
Dont forget to put some type time/date stamp on each record. sometimes ms access will think "another user has changed or deleted the record" and will not allow you to make a change! I found this out the hard way.
In general, it depends :)
I haven't had a lot of problems when the application side has just been updating the data through the forms. You can get warnings/errors when the same row has been updated by more than one user; but Access seems to be constantly updating its live record sets all the time.
Problems can happen if Alice is already working with record 365, and the Bob updates it, and then Alice tries to update it with her changes. As I recall, Alice will get a cryptic error message. It would be easier for the users if you trap these errors and at least give them a friendlier error message.
I've had more problems when I was editing records in the VB code through RecordSets, especially when combined with editing the same data on forms. That's not necessarily a multi user problem; however, you have almost the same situation because you have one user with multiple connections to the same data.
If it's only two users, then Access should do just fine if you put the .mdb on a shared drive.
Have you tried it first rather than just assume it will be a problem.
I believe the recommended max concurrent users for Access is 5 but on occasion I've pushed it past this and never come unstuck.
On the other hand I did once use Access as the front end to MySQL in a single user environment (me). It was a singularly unpleasant experience, I can't imagine it would become nicer with two users.