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.
Related
I have very a rudimentary understanding of Microsoft Access and VBA Code.
On my work desktop, I have Microsoft Office Professional Plus 2013 Access
I've been tasked to create a MS Access application with an Access DB.
I started developing an MS Access application with Forms , and the corresponding DB
I'm using VBA code event handlers(or Event Procedures) for the UI control buttons.
I wanted to create a common configuration settings area for said application( like ASP.NET web application have web.config files or app.config files )
I failed to find anything similar for MS Access application development.
Could someone please provide me with an explanation as to how to implement an MS access implementation model/software design pattern for common configuration settings area that is modular, reusable, clear and concise?
As noted, I great way to do this is to simply create a table in the front end. It is assumed that you will split your database into two parts. The code/forms etc. is the so called front end,and then you have the back end part (the database - it can be a accDB file, or it can be say SQL server).
So the typical update and deploy of your software will be:
Re-link your tables from test database to the actual live production database.
Compile your accDB into a accDE.
Deploy this new updated "next" version of your software to all the desktops.
So, since any change or addition to settings will be in the new front end then any application wide settings you have will thus roll out with your update.
It often depends on the user base. In the case that we had multiple customer sites running our software, then using a local table would not suffice, since things like path names, connection strings to the database etc. are customer specific. So, in this case we moved the settings table out to a text file (setup.ini). So we now use a setup.ini file that is external to the program and assumed to be deployed in the same folder as the front end. On startup we use the windows API to read ".ini" files.
So, both ideas (external setup.ini) or a local table in the front end are rather good choices from a development cycle point of view.
So once you down the road in developing your application, and the table/data structure changes are down to a dull roar, then it is time to split your application. (use the built in split wizard for this). I will say that even for my .net applications, I still often use a external setup.ini file for settings, since once again with multiple customer sites, it not practical to have customer specific settings in the application as opposed to a external settings file.
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.
I have been using MS Access databases via DAO for many years, but feel that I ought to embrace newer techniques.
My main application runs on end user PCs (no server) and uses a shared database that is created and updated on-the-fly. When the application is first run it detects the absence of a database and creates a new empty one.
Any local user running the application is allowed to add or update records in this shared database. We have a couple of other shared databases, that contain templates, regional information, etc., but these are not updated directly by the application.
Updates of the application are released from time to time and each new update checks the main database version and if necessary executes code to bring the database up to the latest specification. This may involve the creation or deletion of tables and/or columns. New copies of the template databases are also included as part of the update.
Our users are not required to be computer-literate and should not need to run any sort of database management software beyond those facilities provided by the application.
It all works very nicely with DAO/Access, but I'm struggling to find how to do it with SQL Express. The databases seem to be squirrelled away in locations that are user-specific and database creation and update seems at best awkward to do by program code alone.
I came across some references "Xcopy deployment" that looks like it could be promising, but there seem to be references to "user instances" that sound suspiciously like something that's not shared. I'd appreciate advice from anyone who has done it.
It sounds to me like you haven't fully absorbed the fundamental difference between the Access Database Engine (ACE/Jet) and SQL Server:
When your users launch your Access application it connects to the Access Database Engine that has been installed on their machine. Their copy of ACE/Jet opens the shared database file (.accdb or .mdb) in the network folder. The various instances of ACE/Jet work together to manage concurrent updates, record locking, and so on. This is sometimes called a "peer-to-peer" or "shared-file" database architecture.
With an application that uses a SQL Server back-end, the copies of your application on each user's machine connect over the network to the same instance of SQL Server (that's why it's called "SQL Server"), and that instance of SQL Server manipulates the database (which is stored on its local hard drive) on behalf of all of the clients. This is called "client-server" or "server-based" database architecture.
Note that for a multi-user database you do not install SQL Server on the client machines, you only install the SQL Server Client components (OleDb and ODBC drivers). SQL Server itself is only installed in one place: the machine that will act as the SQL... Server.
re: "database creation and update seems at best awkward to do by program code alone" -- Not at all, it's just "different". Once again, you pass all of your commands to the SQL Server and it takes care of creating the actual database files. For example, once you've connected to the SQL Server if you tell it to
CREATE DATABASE NewDatabase
it will create the database files (NewDatabase.mdf and NewDatabase_log.LDF) in whatever local folder it uses to store such things, which is usually something like
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA
on the server machine.
Note that your application never accesses those files directly. In fact it almost certainly cannot do so, and indeed your application does not even care where those files reside or what they are called. Your app simply talks to the SQL Server (e.g. ServerName\SQLEXPRESS) and the server takes care of the details.
Just to update on my progress. Inspired by suggestions here and this article on code project:
http://www.codeproject.com/Articles/63147/Handling-database-connections-more-easily,
I've created a wrapper for the ADO.NET methods that looks quite similar to the DAO stuff that I am familiar with.
I have a class that I can use just like a DAO Database. It wraps ADO methods like ExecuteReader, ExecuteNonQuery, etc. with overloads that can accept a SQL parameter. This allows me to directly replace DAO Recordsets with readers, OpenRecordset with ExecuteReader and Execute with ExecuteNonQuery.
Each method obtains and releases the connection from its parent class instance. These in turn open or close the underlying connection as required depending on the transaction state, if any. So a connection is held open for method calls that are part of a transaction, but closed immediately for a single call.
This has greatly simplified the migration of my program since much of the donkey work can be done by a simple "find and replace". The remaining issues are then relatively easy to find and sort out.
Thanks, once again to Gord and Maxwell for your advice.
This answer is too long to right down... but go to Microsoft page, there they explain how to make it: http://office.microsoft.com/en-us/access-help/move-access-data-to-a-sql-server-database-by-using-the-upsizing-wizard-HA010275537.aspx
I hope this help you!!
I am busy developing my own application, it uses a sql server database and it is connected through an entity framework. I use store procedures to insert, update, delete, select from my database.
The app works perfect on my machine even when I publish it. But my problem comes in when I try to install the app to my friend’s computer. It crashes and does not start because it cannot connect to the database.
Is there a way to publish my app with the database, without importing all the tables, store procedures and database into my friend’s pc? I just want to make it so the user just has to install the app and it works.
Your app relies on the db to work, so if you want to put it on your friends PC then you need to make the DB available somewhere, whether it be a local copy or a copy stored on a server somewhere running SQL.
How are you storing your connection string? Is it hard coded in the app or are you utilising the app.config file? To do what you're trying to do you'll need to put the connection string into the app.config file, so you can change it depending on the installation.
either that or
if you want to run your app without data, put a demo flag or something into the app.config file. Put some code into your app to check this value, if it's true then bypass the SQL code and maybe supply some demo data which is hard coded.
Does this make sense?
You could use SQL CE, but you may find it a little more difficult to 'design' your database in it if you are more used to working in SQL Server.
Have you considered SQL Server Express as an option?
On the connection string issue, you can now get the data connection wizard that Microsoft use in Visual Studio via Nuget; this makes adding a way to dynamically configure connection strings on your clients machine much easier.
Lastly, connection strings for the entity framework are different from standard SQL connection strings. Make sure that you clearly understand the differences before you start trying to configure them programmatically. Julie Lerman's excellent book on the Entity Framework explains the differences well.
I'm doing a project with vb.net (smart device) on visual studio 2008 and I need to connect to a database on the device itself (I do not have a physical device to test, only emulation). How should I go about doing it? I would like the database to be in the device on start up.
I've read on the internet that you have to make a reference to System.Data.SqlServerCe but the documents are, in my opinion, vague. So, I'm pretty lost here.
So there are two questions here:
How do I deploy my database so it's there when my app starts?
How do I access that database from my app?
Both are straightforward.
A1. You have a couple options. First, understand that SQLCE databases are a single file, typically with an SDF extension. You can either package it with your app for deployment, so you know it will be there on first run, or your app can check for its existence on startup and crete the file if it's not there. If you need to populate the initial database with data (lookups, etc) then option 1 is probably better. As long as you deploy/crete the database in a persistent storage location (and under WinMo/Pocket PC that's pretty much anywhere), it will always be there when your app starts up.
A2 You are correct that you need to add a reference to System.Data.SqlServerCe, which is again straightforward. Just add a reference in your smart device project:
Once you've done that, you use the SqlServerCe namespace objects to create the database, tables, indexes, etc, insert and query data, and all of that good stuff. Tutorials 2 and 3 on MSDN here are a really good start and they have VB.NET examples. The nice thing is that most desktop examples for VB.NET accessing a SQLCE database will work as-is on the device, and the things that don't work are usually in the presentation of the data, not the actual database access code itself.