Any thoughts on GitHub? (1 Viewer)

[prabha_friend]

Hi Guys...
Anyone using GitHub properly to manage your Access Database and it's codes? Need to know How helpful it would be for an access Database Developer and people constantly working around Microsoft Offices tools...

P.S:
Automating Monster.com to apply jobs (Doing the same task again and again almost sixth time as No backup was maintained)

Need to learn GitHub to avoid reworks. Hope you Help.

With Hope,
Prabhakaran

 

[The_Doc_Man]

Count this as one man's OPINION and not as a cast-in-concrete fact.

I have no experience with GITHUB but lots of experience with developing. When dealing with a multi-developer environment, it is rare to see Access developed this way. The problem is that the structure of Access most easily lends itself to a single front-end file where each module, report, form, query, or macro is held in one (and only one) shared file. IF you use a formal versioning system like GITHUB, you would be able to recover older versions and you could protect against two people maintaining the same thing at the same time. But the problem is that there is only ONE THING being protected - the FE file as a whole. Having multiple maintainers for a single file means they would likely get in each other's way - a lot.

USUALLY you just do a staged development environment for Access. I had a (virtual) server dedicated to the process and it had four folder sets that were more or less identical. That server was backed up daily by our in-house operations staff and the auto-backup software that they used.

I had the DEV environment under a /DEV folder. There is where I kept the master development copy. Any time I was about to make a major feature change, I copied the current FE file and appended a version ID string using underscores to separate the version digits, so PROJECT_2_3_4 (for Project version 2.3.4). That became my master version backup. I usually retained 10 copies on the server, but our backups went back at least five years. The DEV environment had its own back-end file that was a copy of a recent production file. Since the BE didn't change structure very often, it wasn't hard to manage that way.

I had a TEST environment under a /TEST folder. I would copy the recently-developed FE file to TEST and reset the BE links (which is actually easy). Then test it in its own little sandbox. Anything in TEST could be erased in a heartbeat if it wasn't going to be promoted. TEST had its own copy of the BE file.

Because of U.S. Navy and site-related rules, I had a STAGING folder. A successfully tested file would be copied to STAGING where I would do the work required to formalize the internal versioning system that the Navy required and this would get relinked to the production system. The staging area DID NOT have its own BE file.

Then the PROD folder was where the "live" copy of things resided. Users copied the FE from the shared PROD folder, which had a BE file that every copy would reference. But the FE file wouldn't allow itself to be run from the PROD folder. My only regret was that I wasn't not allowed to use the script that would automatically copy the FE file each time a user launched it.

The GITHUB stuff I read online would take care of the version control and would probably help in recovering older versions. However, given the single-file nature of Access front-end files, it would likely get in the way if you had multiple people developing the same file - because versioning systems don't allow simultaneous check-out of a single file.

 

[prabha_friend]

https://visualstudio.microsoft.com/vs/github/

 

[Isaac]

https://visualstudio.microsoft.com/vs/github/

No offense to any Access developer (as I am one myself), but GitHub (and most popular source control /versioning tools - TFS, tortoise SVN, etc) are meant more for the types of programming platforms that lend themselves to sharing code, which Access, of course, does not.
Well ok, I guess except for tortoise, which actually is more like a fancy file explorer. in fact come to think of it tortoise would not be bad for access, but then again, if you're developing in Access, all you can really do is grab a file and work on it yourself and then put it back where you want it to be. There IS no sharing. It's not like SQL Server versioning tools where merging changes and all that magic can happen.

 

[ADIGA88]

I give it a thought a while ago, I think there is two way you can do it.
first, you can put the whole front end in the VMS (version management system), but in this case, I can't see the benefit as you can't use the system features like comparing two versions of codes, etc.
the second option, you can put the modules in the VMS. while there is VBE addons (rubber duck) that allow importing and export of all modules including the forms' modules which this feature is intended for, but there are the forms/reports themself you can't put them in the VMS which will make it hard to roll back or branch the app.

 

[Isaac]

I give it a thought a while ago, I think there is two way you can do it.
first, you can put the whole front end in the VMS (version management system), but in this case, I can't see the benefit as you can't use the system features like comparing two versions of codes, etc.
the second option, you can put the modules in the VMS. while there is VBE addons (rubber duck) that allow importing and export of all modules including the forms' modules which this feature is intended for, but there are the forms/reports themself you can't put them in the VMS which will make it hard to roll back or branch the app.

but that's the thing, because objects aren't isolated (like Functions and Procedures are on sql server), the only thing you can isolate is an entire Module, without extremely elaborate Text comparison which would be a painfully ugly rabbit hole
so one person edits a function in a module, meanwhile another person edits another function in the same module.
replace old module with which one of the 2 people's module version? either way you lose.

 

[ADIGA88]

but that's the thing, because objects aren't isolated (like Functions and Procedures are on sql server), the only thing you can isolate is an entire Module, without extremely elaborate Text comparison which would be a painfully ugly rabbit hole
so one person edits a function in a module, meanwhile another person edits another function in the same module.
replace old module with which one of the 2 people's module version? either way you lose.

I want to make it clear, that I don't recommend the use of any versioning system.

Access is very tied together and you can't apply the separation of concerns principle to allow multiple developers to work on the same app.

 

[The_Doc_Man]

https://visualstudio.microsoft.com/vs/github/

Ah, but you don't develop Access code with Visual Studio.

Visual Studio is better used when you are looking at a MAIN and some number of subroutine/function/data modules. For Access, the MAIN is MSACCESS.EXE, the user interface executable file. You CANNOT modify that and CANNOT make anything else the MAIN entry point. It is why your VBA code is slower than compiled BASIC. You have to use a PCode compiler and INTERPRET/EMULATE the virtual PCode machine to run VBA. But it doesn't matter in another sense. IN THEORY you could "farm out" modules for someone else to build, but there would have to be an extra person to act as "code integrator" so you could put those code elements together when the parts were ready.

 

[Pat Hartman]

I have two types of backup that I make frequently during the day when I am in development mode.
1. I copy the entire FE to two separate folders. One on the server and a second on my local PC.
2. I export all objects to text except for tables/data.

The opening form of my databases is one that checks links to make sure that the user gets a rational message if I accidentally push out a new FE that hasn't been linked to the production tables. If the links are OK, this form hides itself and opens the login form. Since the form remains open permanently, it will be the last form to close. It compares the date of the last backup (kept in a log file) with the change date of objects in the FE and the unload code checks to see who had the FE open, If it is me or someone else responsible for developing, it asks if I want to create a backup. Then either backup #1 or #2 or both is created. Most of the time, I just use style #1. However, over the years, I've had a couple of FE's that were prone to corruption. They would be working fine. I would close and when I reopened, the db was corrupted. So, I developted #2 for these corruption prone apps. Because If I export all the objects as text, and the db refuses to open the next day, I can just import all the text objects into a new, empty db and everything works again.

So, I try to remember every hour or so OR, if I've just made a major change and it finally works to just close the database. That initiates the backup. I reopen the FE and continue. If you pick good stopping points, this process will save your bacon.

Even in the dbs where I don't automatically use #2, I have the code in the db and every week or two, I run a manual export. This is much easier to use as version control since there are tools which will compare two text files.

If you want to use GitHub to manage your code, you might want to export to text all your forms/reports/queries/macros/modules and store those in GitHub. You can't easily check in/out but you can keep versions at least.

Here is a sample with the manual export. You can modify the code to automate it if you want to. I'm working on a sample that has all the bells and whistles but it isn't done. When I finish it, I'll post it. But don't hold your breath.