I have a MS Access Database Frontend that contains a large body of macros, queries, and custom VBA code. This frontend connects through linked tables to our backend access database. In order to allow multiple users to use the database we publish an ACCDE version. For some reason macros are not being included in this published version. Normally you can't see the code but the module names are always listed. This is completely blank, no macros, no vba, and auto exec fails to call a few custom functions as well. VBA code is simply not included.
I've tried:
Compiling the VBA Code -> Works without errors and publishing still doesn't include macros
Saving my frontend as a new file and then publishing
Compact and Repair
Different OS/Different Version of Access/Different Computer
I'm not seeing any errors when publishing, all my references are there, there's no reason for this to be failing as far as I can tell. The only indication that this happened is opening the ACCDE version and getting an error about auto_exec being unable to locate my function.
Ideally I'd like to not have to restore a version and lose changes that I've made.
Related
In order to create an indipendent runtime file.accdr out of a file.accdb, I've downloaded AccessDeveloperExtensions.exe and AccessRuntime.exe and installed them.
Update:
See article Here is the Google Translater .
Update end.
Opening Access 2007 I could create the install package for creating the file.accdr out of the file.accdb.
The problem I get is that an important function does not work anymore. It's the export of a report, wherelse the export of a table still works.
Opening Access I get the following message:
you don't have a source code control program (such as Microsoft Visual Source Safe) installed on
your machine. The source code control commands are therefore not available
I click on OK and Access opens my db.
My db is based on a table, a form, a report and a query. Exporting the report worked in the past, but doesn't work anymore. The message shown is the following:
Impossible to complete output operation. Assure that there are no syntax errors. If the syntax is
correct, reinstall Microsoft Office Accept...
(I've translated the text from Italian).
Now is there another, easier way from reinstalling the hole thing? Because after reinstalling Access I will also have the need of creating databases.accdr and so I have reinstall runtime.exe and DeveloperExtensions again, what would result in the same problems I had before.
Somebody could help?
I am tasked with fixing some bugs that an access 2010 database, written 10 or so years ago, has. The database has been functioning but has a few bugs in report generation that need to be fixed (ie: bugs are not impeding overall functionality).
Since I am relatively new to access 2010, I wanted to create a working copy of the entire database, VBA and all, so that I could get into the VBA code and figure out what is causing the bugs without accidentally sending some of the automatic emails or changing pertinent information in the data. I have tried saving the database with a new name, copying it in the folder and pasting elsewhere, and creating a backup and saving that elsewhere.
Each attempt yields the same issue: the VBA project not being readable. It gives the following message when I open any copy:
if included picture doesn't load: tl/dr: database cant be opened because VBA project cant be read, if "ok" is clicked vba project will be deleted..I have searched high and low, asked everyone that has used the database, nobody knows how to fix the issue and I do not feel comfortable changing anything in the live copy.
Any assistance would be greatly appreciated. Thank you in advance.
One option you might try is to create a new blank database file and attempt to import all of the database objects from a copy of your target database into the new database file using the import wizard. If that's successful it won't be an exact replica of the previous database with regards to settings, but will include all of the database objects/code at least.
My VBA Project seems to be corrupted. When I try to open a module I get a "Module name 'xxxx' is misspelled or relates to a module that doesn't exist". This all seemed to happen after a run time error inferring a corruption had taken place. I have tried to open Access in decompile mode and then open the data base, but still no luck...though I'm not sure how you tell its in decompile mode. I'd desperately like to get some code out that I've been working on for a couple of days.... I can open the tables and queries, so it seems its just the VBA project.
Any ideas? is there a way of accessing the modules outside of the data base?
Background:
I have a MS SQL Server database and I want to track changes to it. For example if a column needed to be added or removed or a table needed to be dropped. Something similar to Version control for regular code.
The problem:
While looking around I saw that there were some tools that can be used:
RedGate SQL Source Control
Visual Studio Database project
I am more interested in knowing if either of these tools will track changes to my database? More specifically I have a TFS server that is the source control for my MVC code, can I use either of these with TFS? Will it allow us to restore from older versions? Will it allow multiple developers to work on the database simultaneously?
For this type of work, ApexSQL Source Control shown to be all that you need. With this SSMS add-in you can work directly on a database, and all of your changes will be tracked in real time.
Yes, several developers can work in the same time on the same database. When one developer works on a one or several objects, other developers can see which those objects are, and until the first one does not finish changing the others cannot change that object, they will not be allowed to.
If by any case, object is changed wrong, previous version or any earlier version can be restored at any moment.
This add-in has all necessary options and features to allow the developers to work without losing time for checking changes made against object, since the add-in does that for them. And you can always see by whom, when and what that change is.
Being in the database version control space for 5 years (as director of product management at DBmaestro) and having worked as a DBA for over two decades, I can tell you the simple fact that you cannot treat the database objects as you treat your Java, C# or other files and save the changes in simple DDL scripts.
There are many reasons and I'll name a few:
Files are stored locally on the developer’s PC and the change s/he
makes do not affect other developers. Likewise, the developer is not
affected by changes made by her colleague. In database this is
(usually) not the case and developers share the same database
environment, so any change that were committed to the database affect
others.
Publishing code changes is done using the Check-In / Submit Changes /
etc. (depending on which source control tool you use). At that point,
the code from the local directory of the developer is inserted into
the source control repository. Developer who wants to get the latest
code need to request it from the source control tool. In database
the change already exists and impacts other data even if it was not
checked-in into the repository.
During the file check-in, the source control tool performs a conflict
check to see if the same file was modified and checked-in by another
developer during the time you modified your local copy. Again there
is no check for this in the database. If you alter a procedure from
your local PC and at the same time I modify the same procedure with
code form my local PC then we override each other’s changes.
The build process of code is done by getting the label / latest
version of the code to an empty directory and then perform a build –
compile. The output are binaries in which we copy & replace the
existing. We don't care what was before. In database we cannot
recreate the database as we need to maintain the data! Also the
deployment executes SQL scripts which were generated in the build
process.
When executing the SQL scripts (with the DDL, DCL, DML (for static
content) commands) you assume the current structure of the
environment match the structure when you create the scripts. If not,
then your scripts can fail as you are trying to add new column which
already exists.
Treating SQL scripts as code and manually generating them will cause
syntax errors, database dependencies errors, scripts that are not
reusable which complicate the task of developing, maintaining,
testing those scripts. In addition, those scripts may run on an
environment which is different from the one you though it would run
on.
Sometimes the script in the version control repository does not match
the structure of the object that was tested and then errors will
happen in production!
There are many more, but I think you got the picture.
What I found that works is the following:
Use an enforced version control system that enforces
check-out/check-in operations on the database objects. This will
make sure the version control repository matches the code that was
checked-in as it reads the metadata of the object in the check-in
operation and not as a separated step done manually. This also allow
several developers to work in parallel on the same database while
preventing them to accidently override each other code.
Use an impact analysis that utilize baselines as part of the
comparison to identify conflicts and identify if a change (when
comparing the object's structure between the source control
repository and the database) is a real change that origin from
development or a change that was origin from a different path and
then it should be skipped, such as different branch or an emergency
fix.
An article I wrote on this was published here, you are welcome to read it.
If you're looking for a product that will track changes into TFS from your SQL Server automatically, I'd invite you take a look at our product, Sql Historian. It's different from most other SQL version control systems (including the ones you've listed) in that it does not require developers to perform a check-in ritual to synchronize version control with what's already committed to the db.
However, features common with Sql Historian and the other two systems you mention are: working with TFS, the ability to view older versions of your db objects, and allowing multiple users on the db at the same time.
I am writing a VBA script to import data from an Access database to a remote database server. (It happens to be PostgreSQL, but I don't think that's very relevant.) At the moment, my scripts are embedded inside an Access database. However, I would like to version my scripts like I do my other source code: as plain text so SVN can give me good change tracking.
I would also prefer not to have to deliver the source files to the client for them to use the script. In other words, I would like to deliver the import tool already compiled into the Access database. Is it possible to do so?
Or am I chasing the wrong rabbit? Is there a way I can use the Access libraries without embedding any code into the Access database? My searching suggests not, but I'm open to the possibility. This is the first thing I've ever done with VBA, so there's a ton I don't know, I'm sure.
I think I was going down the wrong rabbit hole (and I think I was using a non-existent idiom). Turns out that there are some .NET interop DLLs for Office. My machine seems to have the .NET interop DLLs already installed with Office, so all I had to do was add a reference to the Microsoft.Office.Interop.Access DLL and create an application object:
var app = new Microsoft.Office.Interop.Access.Application();
I think a .NET app is going to be more suited to my needs. I'm not going to be doing a lot of Access specific things. This will allow me to have my source under version control as usual. The only downside is that any development machine (and build server, if I automate the build) will need Access installed, but that was going to happen with a VBA script, anyway.
If you don't want to do it within Access, you may want to tag this differently.
You can deliver your database to the client as an MDE file, which is a compiled and stand-alone Access database. The client will not be able to see the modules or other VBA code in this format, if that is your main concern.