I have a small MS Access application that uses the Front end / Back end design. I have decided to lock things down a little tighter, but my front end will not link to the tables if the back end is compiled (ACCDE) too. The linking works fine when the BE is an ACCDB; the thing is, I really need to compile this BE because we don't have a file server to hide it away and there is a small amount of code in the BE just for Highly dangerous (to the data) Admin functions.
There is nothing I am aware of that prevents you opening a front end, and linking to an accDB or accDE back end.
Of course if your back end has no code, so compiling down to an accDE not going to do anything. And it not going to improve security, since an accDE or accDB can freely be opened by Access.
Compiling a accDB to a accDE only strips out the VBA source code, and complies the application down to ONLY having the compiled VBA code. The result is that users cannot changes VBA code, or forms, or reports
However, since the back end ONLY has tables, then there is very little if any advantages to using an accDE in place of an accDB.
So creating an accDE for the back end will actually not result in anything more than giving you a different file extension. (Since no VBA code exists to be compiled).
When you launch the Access linked table manager, it freely allows you to choose an accDB or accDE for the source of those linked tables.
It is possible you done something else to that accDB (or now accDE), but what you done or changed cannot be determined by your post at this point in time.
All in all, to answer your question?
Access allows one to freely link to an accDB or accDE for the back end. There is no obvious reason as to why you are being prevented from doing this, but as a “general” choice in Access, linking to an accDE is allowed.
Yes as stated by Mr. Kallal, there should be no problem. And it turns out there isn't, but in this case the Front end was doing something weird. I though the table link manager was not running, because when I selected 'always prompt for new location' and I selected all tables, usually it would link all the tables at once, however in this instance it was only linking one table at a time and then re-prompting for a location. When I realized it was successfully linking each table individually I repeated the process over and over until all tables were linked. After that, the Front end went back to working as usual, linking all tables in one shot. I'm not sure what was causing the problem; it may have been that I had somehow cross-linked to different versions of the BE and the built-in linkedTableManager process asked for a location for each individual table when it saw more than one original location. IDK. But Thanks for the ears guy... :)
Related
I hardly dare bring up this topic because what is happening is so extremely strange - but I'll try anyway.
I have a large Access DB for a customer. One of the forms in the front end has a series of subforms. Until recently, everything was working well.
Now, when a new version of the front end is sent to the customer (I tried Team Drive as well as WeTranser) this results in one of the subforms being changed to a different form. This form is also in the database but is by no means linked to the main form in question.
I have tested this several times: The version on my PC is still working perfectly. The version that the customer sent back to me according to my request has the wrong subform in it.
We are all working on Access 2010 with an Access 2000 format MDB. The reason for this is that the Backend needs replication.
Does anybody have a clue on how or why this could be happening? Thanks in advance.
Found a solution myself after testing together with the customer.
Copied the file via USB stick this time. The copied file was OK on the destination system. Opened file pressing shift button so no programs would run. Everything was still OK. Then opened the file in the usual way. The start form realized that the paths had changed and relinked all the tables. Except for the start form, no other forms are involved in this operation. After that, the subform had changed to a different form.
Solution (rather: Workaround): Changed the name of the subform that replaced the correct subform. After that, everything went well.
The change of the subform only occurred during the relink routine. If the subform was changed to the correct one manually after relinking, it remained correct.
Reasons? Has Microsoft released updates to MS Access recently? We'll probably never know.
I am about to release an Access Database application where the UI is used exclusively to interact with the database tables.
Whilst I am interacting with the forms during run time, the Visual Basic Editor appears with a line of code highlighted in debug mode, even when no breakpoints exist and no run time error has occurred.
Has anyone else come across this issue?
I need to ensure that the editor does not appear (under normal operating conditions) while the user is interacting with the application.
Thanks.
Yes, I have had this problem too and it has driven me batty. The quick and dirty way of fixing it is to create blank database and import all of the objects from you old database into the new one.
Are your users working with an .accdb file? (or .mdb, depending on the Access version)
If yes, you should convert it into an .accde/.mde before giving it to your users.
Quote from the link:
Additionally, if the database design needs to be secured to prevent changes, Access databases can be locked/protected (and the source code compiled) by converting the database to a .MDE file. All changes to the VBA project (modules, forms, or reports) need to be made to the original MDB and then reconverted to MDE. In Access 2007 and Access 2010, the ACCDB database is converted to an ACCDE file. Some tools are available for unlocking and "decompiling", although certain elements including original VBA comments and formatting are normally irretrievable.
--> since .accde/.mde files are compiled, it's not possible to view the source code at all.
So the VBA editor can never appear accidentally like you experienced...be it because of a breakpoint, some Stops in the code or some strange breakpoint error like yours.
I'm using the Access Developer Extensions to attempt to source control this access database in TFS, however, I'm not sure I am doing it right. I can add a .mdb to source control and create a database from that source control.
I'm probably making a stupid mistake, but I can't figure out how to close the database I created from source control and reopen it while it's still under source.
Does anyone know of any tips or guides on this? I've searched for help on Access Developer Extentsions but I haven't found much. Thanks in advance guys!
I think I found what I was doing wrong. My database automatically compacts on close, so when it tried to do this Access asked me if I wanted "to remove the compacted database from source control". I thought this meant it would just not store the .mdb file, but still keep the objects (like tables, vba, queries, forms, etc) under source. However, this appears to completely remove it... from MSDN:
"Changes to Microsoft Access Behavior
Using the Compact Database Command
In order to take a database that is under source code control and deliver it to a user, you need a way to cut the database's ties to source code control. When you compact a database that is under source code control, Microsoft Access 2000 prompts you to remove the database from source code control.
To remove the database from source code control, Microsoft Access simply removes the Visual SourceSafe properties from the Microsoft Access database and its objects."
http://msdn.microsoft.com/en-us/library/aa155494(v=office.10).aspx
When I said do not remove compacted database from source control, my database and it's objects stayed under source.
Last week I was modifying portions of two modules in an access 2010 db when the program crashed, and would crash every time I tried opening up the db thereafter. I was able to create a new database and import the tables and queries from the corrupted one, but when I tried to import the forms/macros/modules the new database would start crashing also. I keep daily backups, but ended up losing several hours worth of work. This happened twice last week, each time MS Access would crash without warning and the VBA was unrecoverable.
The functionality works as intended until the db crashes seemingly at some unknown point. There must be some sort of issue with my VBA code, since this only started happening when I started modifying the module last week, but I can't pinpoint it since the crashes actually occurred when nothing was being executed. Ie during save.
Does anyone know if it's possible to export the VBA out of access without exporting it to another database? Ie export it without having to use MS Access to do so. On a related note, has anyone created a library that exports query definitions, table schema, and all VBA to text files that I could drop them into source control?
Thanks.
In addition to the method suggested by #Remou, you could try the SaveAsText method to save a code module to a text file.
Application.SaveAsText acModule, "Module1", "D:\Access\Module1.txt"
However, that doesn't satisfy your desire to do it without using Access.
Try a decompile operation on the chance your project includes saved compiled code which has been corrupted. You can find detailed instructions for decompile in the 2 answers to this Stack Overflow question: ms-access: HOW TO decompile and recompile
After decompile, make sure all your modules include Option Explicit in their Declarations sections. Check the project's references, and fix any that are broken (missing). Then run Debug->Compile from the VB editor's main menu to verify your code compiles without error.
Those steps are the best I can offer to reduce potential for continued corruption problems.
For integrating source control with Access, start with this selection of related Stack Overflow threads: site:stackoverflow.com ms-access version control
Folks
We're having the same problem. There is a bug in SP1 that causes it. If you keep opening the database, you'll finally end up with a backup that works - rename the old one BROKEN and remove the _backup from the new database, and you are oky till your next bit of development. Our IT guys (Microsoft Gold Partners) are looking at a fix reported on http://answers.microsoft.com/en-us/office/forum/office_2010-access/access-2010-sp1-you-receive-random-crashes-in/d2bf6175-075a-4a12-a2b1-f55d40af271b
I may go take a look at decompile/recompile however as some of our database have come all the way up from Access 97, to 2000, 2003 and now as mdb/2003 file format still, running under 2010. Having said that, converting to accdb/2007 seems even worse!
So I have a MS Access database at work. Recently I tried to put out another MDE file, that actually took something off a report that was previously there. Now I am getting this error that says, "MS Access cannot create the MDE" with a little show help button....click the show help button and it gives a description about this relating typically to too many objects (Forms, reports, tables, etc). This database is not very big at all, so I am wondering how this could be happening?
Does it count each time I release an MDE with only minor changes, all the same forms, reports, etc over and over again?
Could this be another error and the pop up box is kind of blanket or generic?
Is there anyway to solve this?
Does this count objects on a form/report (text boxes, cmb boxes, etc)?
Basically the example given in the help says that if you have 500 forms, and 2 modules for each form, then that would count as a 1000....this database has about 12 forms, 4 queries, 16 tables (max record = >1000 records) and is not very big. Since the last time I released an MDE with no problem, I have only tried to deleate an item off a report for this new one, without adding anything new.
Please help....there are screaming for this, and I am at my wits end!
Thanks
Yes, this is a misleaidng and blanket error message. Try compiling your code. Ctrl+g >> Debug >> Compile should tell you what line of codes is/are causing your problem.
I would suggest compiling your code on a frequent basis. I do so every few lines of code.
Chances are you had some code in the report referencing the control you removed from the report.
Objects count for the life of the database, that is, even if you delete them, they still count. I suggest you decompile, compact & repair, and then copy everything into a fresh database, which will get you a nice, clean copy. Make sure it compiles and then create your mde.