Build from source fails VCS 3.4.17 - 'unable to determine database file name' #273
Comments
|
Had the same problem. Sadly i couldn't find the problem yet. The same database can be exported/imported in the vcs-version before. |
|
What was the previous version of the add in you had? |
|
What you may need to do is to build from a prior addin, then upgrade the addin, then export the build.
This is probably what you'll have to do if you're building from an early 3.x version, as we made some fairly significant updates to the way things export and import; if you have ANY encryption in your existing code base, you will need to do the above to 'upgrade' your addin, as the encryption was completely removed. |
Exported using VCS 3.4.17, it does not Import using VCS 3.4.17 |
This was exported using VCS 3.4.17. It does not import using same version. |
|
@alanv73 do you know if you have any fancy column names in your database? What's the language your machine uses? Also, can you provide the export log? |
|
#272 is a separate issue, but the same version of Office is used.
Define fancy? It was an inherited database so I can't say for sure. Maybe?
US English, Windows 10 20H2 Export.Log: |
|
Thanks for this; from what you've posted so far, #272 and this one are caused by the same issue, but different materializations.; does this one happen first then the other one? From what you've posted, it appears that the subfolder ("Rentals") does not match the database name (Residential). There should be a folder in "..\rentals" called "Residential.accdb.src" unless you've configured your export folder to differ. What folder are you exporting to? Export Folder Configuration If you can clear that out, and try export/import does this help? Can you post what settings you have for the export tab? Thanks! |
|
@hecon5 - Sounds like you are on the right track... The export settings would be helpful to know in this case. @alanv73 - If it's easier, you can also upload a copy of your |
|
I cloned my repo to \Rentals then attempted to build from there. I tried building from the current branch, also tried rolling back to a previous commit (when the db was exported using VCS 3.3.17). Both attempts failed with different symptoms. vcs-options.json |
|
@alanv73 - Thanks for posting the config. That is helpful in understanding what you are trying to do. 👍 It looks to me like the issue here is probably related to using an absolute path in the export folder. While this is technically supported, it requires a matching corresponding property in the current database so that the database can correctly find the export folder. When it comes to building from source, it will attempt to look up the original path from the That being said, may I make a suggestion? If you are able to make some changes to your development configuration, you might be able to simplify a lot of this. Let me explain what I do, and you can see if it makes sense in your environment. I treat the online git repository (GitLab/GitHub) as the final authority and storage of the source files for each project. I create a separate project for each database. I treat my computer as a development workstation where I clone the repository to a local folder on my computer and make my changes to the database. Periodically throughout the day I export source and commit these changes to git. I don't worry about saving my database file or source files on the network, since all the changes are being constantly uploaded to the git repository. The actual binary database file (*.accdb) is excluded from git using the When it comes to deployment, I am not working on the live production database. I am working on the development copy in my local git clone of the project. (The export folder option is blank, so the database is simply exported to a In my opinion, the real game-changing paradigm shift with this add-in is that you no longer have to be so careful with the binary Access database files (*.accdb). The real foundation for each project is the exported source files, which can be used to build any version of the database in the git repository. Those source files become almost self-documenting as you make changes to your project. No longer is the database a black box where you wonder what changed, but you have a clear record of all the changes that took place over time to the individual database components. Hope that helps!! |
|
This is what I do, and it works so much better than worrying about someone on the network breaking everything like a toddler holding a balloon and dog, while running through a glass shop at full speed. Downside is that when I break stuff real good, I have no one to blame, and can't blame network gremlins or anyone else anymore. |
|
@Geforced; can you check your export location, as well, and see if you're exporting to an explicit path (or, really, anything other than if that field is blank). |
|
After looking at this again, I'm reasonably sure that what's happening is that your export location is either not accessible or somehow the addin is looking at your local folder and not the remote location. If the database you're building ( Details:Since the remote location (\... file) is where you exported your code from, but your local location (C:...) is where you're trying to build from, and there's nothing there (because you exported to your remote location), it will not find any source files, despite having JUST exported. @joyfullservice: I think the fix here is to add the export location, and the exported file location (as they can differ as we see above) to the export log (full path, not relative). The other thing to check is during the build log have it put the above in the import log and ensure those details are exported even on a failed build. That said, I think the above is the expected result when using explicit export paths and losing the network location. |
My workflow isn't much different from this except for the remote export location, and differing build location. It's disappointing that I can't set these to whatever I like. If I'm a new member of the team and have to build my dev database from source, how do I know where to clone the source? |
|
To test my theory, clear out the export path, export it in your local dev file, and try rebuilding. If that works, it means you can clone to your local machine,and don't need the export location accessible |
You should be able to set the export folder to an absolute path. (There are others out there that use this functionality.) You just may encounter issues if you rename the database file or change its location between export and build.
What system are you using for version control? Are you using a local file-based system, or an online service? In my environment, we use a local GitLab server (free, open source) for internal projects. For remotely shared projects we use private repositories on GitLab.com. (Also free) Cloning the repository is very easy using the GitHub Desktop application. The team members all know that these git servers are where they can find and clone the projects. I used to keep the repositories on shared network folders, but after moving them to the cloud, I have never looked back. There are many additional web based features available on GitLab (and GitHub) that help streamline the development experience. Of course you still need a backup/disaster recovery plan, but I find it works well for us. |
|
Poking around the code a bit more, I think there might be something to this, and I'm not sure how it would be possible to deal with at the moment. Why this hasn't reared its head until now I'm not sure. @alanv73: Did you CLOSE access after exporting then reopen with the file at the "local" location? (C:...)? The other question is: What was the previous Version Of VCS where this DID work? You mentioned the remote export/build worked before, but I'm not sure which version you upgraded FROM. The build routine is looking (according to the first post here) is looking in This indicates that the options or configuration file isn't loading the correct path for the source information. Looking in the code, I see this: clsOptions.cls.LoadProjectOptions:
' Get saved path from database (if defined)
strSaved = SavedSourcePath
' Attempt to load the project options file.
If strSaved <> vbNullString Then Me.ExportFolder = strSaved
LoadOptionsFromFile Me.GetExportFolder & cstrOptionsFilenameWhich indicates that for whatever reason I think it might be by design impossible to build a remote location after you close the database and move the file, unless you also move the Bottom Line:If you're using a hard-coded export location and your development copy is anywhere not that location (eg your local machine), the tool works only in Export mode. If you want the features of building, too, then you'll need to have them colocated, or use relative paths. Looking further, I'm more perplexed as to what happened between V 3.4.17 and the prior version, I thought they'd put which one did work, but they didn't. |
Can you tell me what version you had before that DID work? |
|
One solution that may or may not have unintended consequences is to locate the configuration files, or at least the location of the config files in the directory with the addin ( Obviously, there are tradeoffs to this, so I don't think storing it in the same location is a good idea, or even storing it at all is the right choice. The more I think about it, the more I wonder if because of the improvements to building and exporting, if the export path (other than relative paths) is even required at all to continue functionality; perhaps another way to deal with this is to have this be a "backup export" and still export to a local relative path. This way, the export files are all relative to the file, they're all in a fairly standard location, and if you move / rename the file, the path changes with it so you can keep both version's files. |
Yes To boil this down, the build process fails if I clone the repo to any folder other than the default. It also fails if I name the database file anything other than what it was originally named. I cloned the source to the default folder (Residential.accdb.src), created a blank database file with the EXACT name as the original (Residential.accdb), and it built successfully (after a few tries). The only other problem was that it doesn't tolerate errors very well. I had a json file that was supposed to be deleted from the repo, but showed up when I cloned it. That caused Edit: Also, if I roll back to a previous commit (it was exported using vcs 3.3.17), I get a build error; Edit 2: Moving forward through the git history, I tried a commit that was exported using vcs 3.4.16 and got this error: |
|
ok! This is great news (yeah, I know, it's 'broken' but it's working like it should (I think)!). To make sure we're helping you properly, I'm going to make sure my terms are matching your terms:
From what it sounds like, because your config points to the Can you try this experiment for me?
If it does, you can clear out the export location on your |
|
@alanv73: Did 3.4.16 work for you? There's only one change that happened between .16 and .17, and it has to do with the |
This works. It also works if I:
What doesn't work no matter how it was exported is:
See error messages above. |
|
Ah, ok! This is interesting, I'm curious why the If you're needing to roll back one of (your internal) changes to your database, I'd suggest rolling back to the VCS that worked for you while you get that done, then upgrade to the latest. From V3.4.15 on we made some significant improvements to how Modules and classes are imported/exported, and forward-only was expected. (If you need to build a previous version, can always downgrade the VCS to a prior version and then build, then upgrade VCS and rebuild, but typically, this was a low risk event. From a development standpoint, my team's processes don't allow tool (VCS being one of them) updates mid-sprint / feature implementation for this reason; we want to control all change where possible. Once the sprint is over/implemented, we then look at each tool update and see if it is the right time to roll in those. It sounds like this might be something that got you, too. For instance, one of the updates we're making on our internal team is still using 3.4.15 until we get it rolled out, so that we can roll back where needed without dealing with tool caused mayhem. Going forward, for your environment, it sounds like with the repositories you're using, leaving the |
|
To close this out: were you able to export/build with a remote location previously and it has now broken, or were you previously just exporting and then tried building only after you updated to I opened a new issue to discuss this, as I'm not positive the experience you are having is a bug, as I think it might be up against some design limits, but want to get you supported and on your way using this tool. |
I wasn't building on the reg. If I were to term something a bug it would be:
I guess it's up to you to decide if one or more of these things is outside design limitations. |
|
Here's my thoughts, what are yours on these? Also, FWIW, when you say "arbitrary" I presume you mean "absolute path location"?
That said, for Item 3 above, I do think perhaps we should revise versioning numbers so that it's clearer what's not going to allow backwards compatibility and what will. Perhaps a revised Wiki Page stating that would be helpful. |
Maybe the answer is to better document the requirements. As long as a person can |
|
This we can do! I'll see if I can get some time to document the folder structure and put it into the Wiki. I think this would help others who work on the VCS Add-in itself, too, to know the intent and what pieces are needed. |
|
Thank you all for the input on this issue. I was able to reproduce it on my system as well. While the recommended approach for new projects is to use a blank export path, I recognize that some environments and workflows require other configurations, and I think it is reasonable to support these alternate configurations. I have added an additional |
Added a new property to save the database build path in the source files. This restores the intended functionality of being able to build from source even when the source folder is in a non-relative location such as another physical drive or network location. Fixes #273
Added a new property to save the database build path in the source files. This restores the intended functionality of being able to build from source even when the source folder is in a non-relative location such as another physical drive or network location. Fixes #273
Exported using VCS 3.4.17
no build log created
The text was updated successfully, but these errors were encountered: