I'm looking for a way to implement SCM over multiple Access 07 databases. We just need source control for the forms/code.
Essentially we have 100+ databases that are structured the same, use the same code/modules, but each contains data for just one client. When we make a code change we currently have to manually go through each file to make the change.
Has anyone implemented source control for something similar(God help you if so) or have any ideas?
PS - I realize there is lots of DailyWTFery in here, this is a legacy product I've been assigned to do some emergency maintenance on before we rewrite to .NET/MSSQL, but I think there's enough work to warrant putting this in place if it's possible.
You can find out more how to do SCM in this question; it does involve exporting and importing the code and forms using some undocumented (or poorly documented) commands. I also recall issues with checksums or version numbers happening when you used that method.
However, you could solve a lot of this problem by separating the the data and the application sides of the DB into separate files and then adding table links to the data DB from the application DB. Then you would have just one Application DB, and oodles of Client data DBs.
Switching to a different client is as simple as re-linking to the other DB.
You can do that manually or code it with a structure something like this:
Dim myTable As TableDef
Dim db As Database
dim strDBPath as string
strDBPath = ";DATABASE=C:\workbench\MyNewDB.mdb"
Set db = CurrentDb
db.TableDefs.Refresh
For Each myTable In db.TableDefs
If Len(myTable.Connect) > 0 Then
myTable.Connect = strDBPath
myTable.RefreshLink
End If
Next
'' Note: This whips through every table in your database and re-links it to the new
'' DB. ODBC links will have a different value for strDBPath - I'll leave that as
'' and exercise for the reader
Related
My current team of 20 people uses an access database front end on their desktop. The backend of the access database is on a network drive. I have been asked to create an access database front end with MYSQL as the back end.
I have installed the MySQL workbench and the ODBC connector on my computer. I have created the schema and tables and I have connected the front end of the database connected to the MYSQL table I created in workbench. My question is
How do I deploy this for the team to use. I believe I can move the front end of the access dB to the network drive and the team can copy it to their desktop. But what do I do about the backend?
Does the team need to have the ODBC connector installed on their computers?
Should I move the MySQL workbench to the network drive?
PS: I am a new developer and just learning about databases and I am only familiar with the access database please go easy on me.
Thanks.
SO is for questions about coding, so this is OT. However:
One method is described in my article:
Deploy and update a Microsoft Access application with one click.
The old backend, you can archive. It will not be used anymore.
Yes.
Probably not. It is only for you, should you need to modify the
MySQL database.
Well, first up, you STILL need and want to deploy the application part called the front end (FE) to each workstation.
So, after you migrate the data to MySQL, then of course you will use the access linked table manager, and now link the tables to MySQL. How this works is really much the same as you have now. The only difference is that you linked tables now point to the database server (MySQL). From the application point of view, it should work as before.
Like all applications, be it Outlook, Excel, accounting packages? You STILL deploy the application part to each workstation. So just because YOU are now developing and writing software with Access does not mean out of the blue that you now for some strange reason STOP deploying the FE part to each workstation. In fact, you should be deploying a compiled version of your application (a accDE).
A few more tips:
WHEN you link the FE, MAKE SURE you use a FILE dsn. The reason for this is Access converts the links to DSN-less for you. What this means is that once you link the tables, then you are free to deploy the FE to each workstation and it will retain the linked table information WITHOUT you having to setup a DSN connection on each workstation. You will also have to of course deploy the MySQL ODBC driver to each workstation as that is not part of Access nor it is part of your application.
So just because you are now developing software does not suggest nor get you off the hook of deploying that application to each workstation. So, your setup you have now with a FE on each workstation does NOT change one bit.
For the most part, after you migrate the data to MySQL, then likely setup your relationships (say with MySQL workbench) there are several other things you need to keep in mind.
All tables now need a primary key. You likely have this, but Access with a access back end did and could work on tables without a PK. However, for SQL server/MySQL etc., then all tables need that PK.
Next up:
If you have any true/false columns, you MUST set a default up for that column. If such true/false columns have a default value or allow nulls, this will confuse access - so ensure that true/false columns can't have nulls and have default (useally 0) setup on the server side.
Add a "rowversion" column. This is not to be confused with a datetime column. In SQL server this rowversion column is of timestamp data type (a poor name, since the column has zero to do with time - it is simply a column that "versions" the row. This will also eliminate many errors. I don't know what this type of column is called in MySQL, but all tables should have this column (there is zero need to see/use/look at this column on your forms - but it should be part of the table.
All of your forms, reports and code should work as before. For VBA recordset code, you need this:
dim rst DAO.Recordset
dim strSQL as string
strSQL = "SELECT * from tblHotels"
set rst = currentdb.OpenRecordSet(strSQL).
You likely in the past had lots of code as per above.
You now need:
Set rst = CurrentDb.OpenRecordset(strSQL, dbOpenDynaset, dbSeeChanges)
You can generaly do a search and replace (find each .OpenRecordSet, and add the dbOpen and dbSee to each line of code you find. (I put the dbOpenDynaset, dbSeeChanges in my paste buffer. And then do a system wide search. It takes a few minutes at most to find all .openRecordSets
At this point, 99% of your code, forms and everything should work.
The ONE got ya?
In access be it on a form or in VBA recordSet code? When you create a new row, or start typing on/in a form? Access with access back end would generate the PK at that point. There was/is no need to save the record to get the PK value. This need is rare, and in a large application I only had about 2 or 3 places where this occured.
So, if you have code like this:
dim rstRecords as RecordSet
dim lngPK as Long ' get PK value of new record
Set rstRecords = CurrentDb.OpenRecordset("tblHotels")
rstRecords.AddNew
' code here sets/ add data/ set values
rstRecords!HotelName = "Mount top Hotel"
rstRecords!City = "Jasper"
' get PK of this new record
lngPK = rstRecods!ID ' get PK
rstRecords.Update
So, in above code, I am grabbing the PK value. But with server systems, you can NOT get the PK value until AFTER the record been saved. So, you have to change above to
rstRecords.Update
rstRecords.Bookmark = rstRecords.LastModified
' get PK of this new record
lngPK = rstRecods!ID ' get PK
Note how we grab/get the PK AFTER we save.
The bookmark above simply re-sets the record pointer to the new record. This is a "quirk" of DAO, and WHEN adding new reocrds, a .Update command moves the record pointer, and thus you move it back with the above .LastModified. You ONLY need the .LastMOdifed trick for NEW reocords. For existing, you already have the PK - so it don't matter.
This type of code is quite rare, but sometimes in a form (and not VBA reocdset code), some form code we might use/need/get/grab the PK value. In a form, you can do this:
if me.dirty = true then me.dirty = false ' save reocod
lngPK = me.ID ' get PK
So, once again, in the above form code, I make sure the record is saved first, and THEN I grab the PK value as above. Of course this is ONLY a issue for NEW records. (and you don't have to use the bookmark trick - that's only for recrodsets - not bound forms.
So, just keep in mind in the few cases when you need the PK value of a NEW record, you have to do this AFTER you saved the recordset (update) or in the case of a form, after you forced a form record save. This requirement is only for new records and ALSO only when your code needs to get/grab the new PK value.
Other then the above two issues? All the rest of your existing code and forms should work as before.
I have an Access Database which I populate using a pass through query.
I get specific data from an SQL database and dumps it on Access.
This Access DB is updated weekly but I cannot simply append new data from the previous week because all other past weeks also updates.
What I did is truncate the Access DB and then load everything again.
When I do that, I need to Compact and Repair the DB so that the size doesn't bloat.
My question is, is it ok to do that? Currently I am using the logic posted in this answer.
I have not encountered any problems yet but I just want to make sure and get our access guru's thought about it. Also I'm planning on doing a scheduled run on our server to do the task.
Just need to make sure that it will not get corrupted easily (what is the chance of corrupting the file in the first place?).
If you'll ask, why do I need to do this? Users of data have no access on SQL server.So I have to pull data for them so they can just connect to Access DB instead.
Just in case you need the code:
Dim sqlDelete As String
Dim sqlAppend As String
sqlDelete = "DELETE * FROM dbo_Table;"
sqlAppend = "INSERT INTO dbo_Table (Col1,Col2) SELECT Col1,Col2 FROM passThrough;"
With DoCmd
.SetWarnings False
.RunSQL sqlDelete
.RunSQL sqlAppend
.SetWarnings True
End With
Application.SetOption "Auto Compact", True
If you need to truncate the data and load again I would recommend to move all tables, which should be truncated and all temporary tables to separate database.
After separating it will be possible to replace this database with unnecessary data by empty database file when the application starts. Just save a copy of empty database and copy this file over existing database with old data. This should be done before opening any form/recordset based on tables from temp database. It will work faster than C&R each time and more reliable, because sometimes C&R may damage the file.
Template database file also can be stored in main database in Memo field
I will refer this forum post: http://www.utteraccess.com/forum/index.php?showtopic=1561733
I'm working on an Access 2003 database, divided into front and back ends. I've attempted to compact and repair the database, which appears to do nothing.
After running various export processes I noticed that some of the columns reported as transferred didn't seem to tally with what was displayed in the design view.
Public Sub Test()
Dim db As Database
Dim td As TableDef
Dim f As field
Set db = CurrentDb
Set td = db.TableDefs("TBL tablename")
For Each f In td.Fields
Debug.Print f.Name
Debug.Print f.Properties("ColumnHidden").value
Next f
Set f = Nothing
Set td = Nothing
Set db = Nothing
End Sub
Further tests ascertained that the table actually had several fields, some of which were replication fields (the database had previously been replicated, but not anymore). More importantly, some of the fields were required data fields, containing data necessary to the project.
I have some questions regarding this:
Is there a setting in the background that allows the field to be hidden in design view?
If not, is this a good indicator of corruption?
Update
I've tested the theory further by writing a query to pull the data back, which also works fine:
...and the table design...
Update (06/06/2016)
I've written a process to extract as much data as possible from the database and drop it into a new one. Though I don't think Microsoft Access is a suitable platform for this application, at present it will have to suffice. In the future, I will attempt to move it to SQL Server to stablise its operation, but in the meantime it will have to serve as is.
I've posted the solution I used to do this here.
I'm going to accept the fact that this database is corrupt. There were too many issues boiling up, including:
Missing fields in tables
Tables not copying to other databases
Inability to compact and repair the database (the C&R would return instantly without doing anything)
Inability to remove the replication applied to the database
What i have is the Issues template from microsoft which is all i really need for its purpose. I have converted it so that is now no longer a web database by exporting objects as client objects.
I want to split this database so that not only multiple users can utilise it at the same time but also so it performs better.
When i split the database the macros linked to the tables go to the backend so when the front end needs to use them it errors.
Below is and example of the add comments macro that gets called when the add comment button is pressed on the front end.
And this is the macro embedded to the button
Can these be converted to VBA and interact with the backend the way it is meant to and if so where would i start. I have looked for an answer but all i find is people saying "it is fine now i have gone vba route" or similar but not actually showing it working.
Below is the converted data macro to VBA. It isn't 100% there yet as I have hard-coded the userID but this will be fixed later today, but I hope it gives a good understanding of how to convert data macros to VBA because this was a learning experience for me.
Private Sub cmdAddaComment_Click()
Dim db As dao.Database, theComments As Recordset
Set db = DBEngine.Workspaces(0).Databases(0)
Set theComments = db.OpenRecordset("Comments")
theComments.MoveLast
theComments.AddNew
theComments!IssueID = Me.ID
theComments!CommentDate = Now
theComments!Comment = Me.txtAddComment
theComments!UserID = 2
theComments.Update
Me.txtAddComment = ""
DoCmd.RepaintObject acForm, "IssueDetail"
End Sub
Before doing this, make a backup of your database. You can do that by closing down the database, then locate the .accdb file on your computer, and press Ctrl+C and Ctrl+V
You can do your own split like this:
Create a new, blank database.
Import everything EXCEPT THE TABLES from the old database
In the new database, create links to the old database tables. To do that, click on External Data - Import & Link, and then click on Access. Select the Link option, then locate the old database, and select all the tables you want to link. Note that if you see any tables that are named like "MSYS", do NOT import those. Those are system tables, and Access will handle those internally.
Now delete everything EXCEPT THE TABLES from the old database.
Your new database is now "linked" to the old database's tables, but all Forms, Reports, etc are in the new database.
If you want to split an Access DB, you have to separate TABLES from all the rest.
Queries, Macros, Forms, Reports and VBA code have to stay on the frontend, and only tables on the backend.
What you are missing are the LINKS from the frontend to the backend tables.
To do that you need to create a copy of your DB, renaming it "BE.mdb" (or accdb), delete all your objects except tables from BE.mdb.
Now on the original mdb, you need to delete every table and add a link for every deleted table to the BE.mdb corresponding table. This can be done from the Import menu, choosing "link table" instead of "Import table".
I am looking for a way to manage syncronization between an Access mdb file for an application, and a MySQL schema containing a copy of the same tables. This arose from the fact that the application doesn't support MySQL as a backend, but I am looking for a way to utilize MySQL for other in-office applications using the data the first application generates.
Some givens:
1> We cannot abandon the first application, and it's only compatible with Microsoft SQL Server as a backend server to house data.
2> We are not against using Microsoft SQL server, but the licensing cost is a big concern - as well as rewritting some other Access applications written to use linked tables and seperate mdb files.
3> The database server should be "PHP friendly" for a future expansion project for an internal corporate intraweb.
4> No data needs to be, nor should be allowed to be, accessed from outside the corporate network.
I hope I am not being too obscure, but I don't want to break confidences either - so I am trying to walk a pretty tight rope. If anyone can help, I'd greatly appreciate it.
Synchronizing two databases is very, very complicated if both databases need to be updatable. If one is a slave of the other, it's not nearly as difficult. I have more than once programmed just this kind of synchronization using Access, once with an MDB on a web server that had to be synched with a local data MDB (to incorporate data edited on the website; no edits went back to the website, so one-way synch, but still the need to merge edits on the non-web side), as well as once programming a synch between MySQL on a website and Access in a master (MySQL) / slave (Access) relationship.
On the website, you program a dump of data for each table to a text file. It's helpful to have timestamp fields in the MySQL tables so that you know when records were created and updated. This allows you to select which records to dump since the last data dump (which makes the synchronization of data on the Access side much simpler).
The way I programmed it was to then import the text files into staging tables that were indexed appropriately and linked to the front-end Access app. Once the data dumps are imported into the staging tables, you then have three tasks:
find the new records and append them to the Access data store. This is easily done with an outer join.
deal with the deletions. I'll discuss this later, as it's, well, complicated.
deal with updated records. For this, I wrote DAO code that would write column-by-column SQL statements.
Something like this:
UPDATE LocalTable
SET LocalTable.Field1 = DownloadTable.Field2, LocalTable.Updated = DownloadTable.Updated
WHERE LocalTable.Field1 <> DownloadTable.Field2
Now, obviously, the WHERE clause has to be a bit more complicated than that (you have to deal with NULLs, and you have to use criteria formatted appropriately for the data types, i.e., with "" and ## for text and dates, respectively, and no delimiters for numeric data), but writing the code to do that is pretty easy.
Skeleton code looks something like this:
Dim db As DAO.Database
Dim rsFields As DAO.Recordset
Dim fld As DAO.Field
Dim strSQL As String
Set rsFields = db.OpenRecordset("SELECT TOP 1 Field1, Field2, Field3 FROM LocalTable;")
For Each fld in rsFields
[write your SQL statement and execute it]
Next fld
Set fld = Nothing
rsFields.Close
Set rsFields = Nothing
Set db = Nothing
Now, as I said, the complicated part is writing the WHERE clause for each SQL statement, but that's pretty easy to figure out. Also, note that in your rsFields recordset (which is used only to walk through the fields you want to update) you want to include only the fields that are updatable, so you'd leave out the CREATED field and the PK field (and any other fields that you don't want to update).
Now, for the DELETES.
You might think it's a good idea to simply delete any record in the local table that's not in the remote table. That works fine if it really is a slave database, but so often what is originally a slave ends up getting its own edits. So, in that case, you need to not delete records from the master MySQL database, and instead have a DELETE flag that marks records deleted. You could have different varieties of logic that could clean the deleted records out of the master database (e.g., if you're using date stamps in the records, you could delete all records flagged DELETED with LastUpdated timestamp that is <= the last time you dumped the data; alternatively, you could have the Access app send a text file up to the server with a list of the records that have been successfully deleted from the Access data store). If there are edits in the Access data store, then you'll need some logic for dealing with an edit there on a record that was deleted from the MySQL "master" database.
In summary:
If you have a true master/slave relationship, it's fairly trivial. If you really wanted to do it by brute force, you'd just dump the entirety of all the MySQL data tables to text files, delete all the records in your Access data store and import the text files.
I would tend not to do that, as the first time you need to depart from the pure master/slave relationship, you're hosed and have to rewrite everything from scratch.
The outline I gave above will work very cleanly for master/slave, but will also work well if you have a few fields that are private to the "slave" database, or data that exists in the slave and not in the master (which is the situation I was working with).