I have multiple versions available in Version Control of my Spreadsheets Script editor. The most recent one is after a complete rewrite of the server side commands and malfunctions terribly at the moment. I have reverted to the last known good version and things are working well at the moment, but something small has come up that requires changing. Here is the issue - i no longer seem to have access to the source of the old version. I can choose to make the old version live, so i figure the source might still be stashed somewhere. Can it be accessed?
Related
TLDR:
Our Google Spreadsheet is broken and cannot be edited / saved. It keeps saying Trying to reconnect. To edit offline, turn on offline sync when you reconnect, and Reconnecting. Can it be due to the many versions saved? If so, what can be done if we don't want the sheet to change its ID?
Any help is highly appreciated!
Detailed Background:
We have a large Google Spreadsheet in our project (< 700k cells) and it's well under the 2 million cells size limit as described in here .
We have been programmatically updating this sheet by creating CSVs in the google drive with python, then using Google App Script to update the sheet with contents from the CSVs.
It has been fine for several weeks, today we started to have an issue, that is, when we manually open the sheet, it just keeps saying "Trying to reconnect. To edit offline, turn on offline sync when you reconnect", and "Reconnecting". We can make no changes to the sheets.
We tried to use different browsers (chrome, firefox, edge) and different OS (Windows, Mac), and we still have the same issue. So I don't think it's anything related to firewall / browser configuration.
We tried to make a copy of the sheet, and we are able to make changes to the copy. We can also access any other sheets and make changes without any problem.
The only difference between the actual sheet and the copied sheets is probably that the actual sheet has a lot of old versions (it has been updated every 3 minutes for weeks). Can that be a reason of failure to edit?
Another possibility is that many other scripts read this sheet. Can this be why? (It will be a pain to stop all the scripts / redirect all the scripts to another Spreadsheet)
Thanks a lot in advance!
Additional Details / Conclusions:
Using a database is definitely a better idea than a spreadsheet for such a large scale dataset.
An ".edu" domain was used. I believe we are using the G Suite version.
Just like the PC case, I am unable to make any changes when I use mobile version on Android.
From various sources, it seems that the old versions cannot be deleted (http://www.sevenminutescientist.com/2016/06/03/no-you-cannot-remove-a-revision-history-from-a-google-doc/)
When I look into the version history, it shows the following: "Google Docs encountered an error. Please try reloading this page, or coming back to it in a few minutes." I am unable to access any of the old versions.
Having issues with Google Drive constantly disconnecting you in Chrome? Error message: “Trying to connect. To edit offline, turn on offline sync when you reconnect”
This issue was encountered on a PC running Windows 10 64bit and Google Chrome (happens in the 32-bit and 64-bit versions). It doesn’t appear to happen in Firefox.
Cause: Kaspersky SSL Scanning (although it may still be an issue in Chrome as it doesn’t happen with other browsers and will likely be fixed by one of the parties soon)
Solution: Disable Kaspersky 2015 Encrypted Connection Scanning. Settings > Additional > Network > Disable encrypted connection scanning. NOTE: even if you disable Kaspersky via the temporary disable feature Google Docs still doesn’t work you have to turn off Encrypted Connection Scanning as it’s obviously always running even when Kaspersky is temporarily stopped (another bug as turning Kaspersky off should disable this).
I'm trying to change the SQL query under the SQL tab in PhpMyAdmin but the old code keeps coming back every time I navigate off that page (and thus, giving me an error message again). How can I stop it from reverting back to it's old erroneous code? I have the new code at the ready. Is there some sort of setting I need to tweak?
Actually, I don't really need any code here at all, unless it's required. I'm new to PhpMyAdmin and just want to set it up so that I can follow along with a video tutorial.
When I try to click on the Databases tab
The old code in the SQL tab. Keeps coming back...
Note: The code was changed to that shown below that works. But it "reverts" back somehow. Good code:
It appears to be a version incompatibility. Your screenshot shows you using MySQL version 5.7 with phpMyAdmin 4.2; this is not supported and guaranteed to not work properly. For use with MySQL 5.7, you should use the latest phpMyAdmin (which is currently the 4.6 branch; 4.6.4 was released on 2016-08-16).
For more information about version compatibility, see the "Requirements" section of the documentation included with each download, or the information listed with each version at https://www.phpmyadmin.net/downloads/
Wondering if it is possible to have a version control of a MySQL database.
I realize this question has been asked before however the newest is almost a year ago, and at the rate things change...
The problem is coming that each developer has apache/MySQL/PHP on their own computers to which they sometimes edit the database. Its rather inconvenient if they have to send an email to all the other developers and then manually edit the test servers database.
How do you deal with this problem?
Thanks
This is not a MySQL-related solution in itself, but we've had a lot of success with a product called liquibase. (http://www.liquibase.org/)
It's a migration solution which covers many different database vendors, allowing all database changes to be coded in configuration files, all of which are kept in Subversion. Since all configuration is kept in XML files, it's easy to merge other people's changes into the mainline script and it plays well with tags and branches.
The database can be brought up to the current revision level by running the "update database" command. Most changes also have the ability to roll-back a database change, which can be helpful too. I would recommend following the practice of making sure you get current before running the migration, as this would likely be easiest.
Finally, when it comes to a production delivery, you can choose to have all the database changes output as a full SQL script so it can allow DBAs to run it and maintain a separation of duties.
So far, it's worked like a charm.
Well we use Rails which keeps all the change in the migration files. I know that a couple of PHP frameworks do the same thing - Symphony for instance. So when all the changes are merged in our repository ( we user mercurial) - we can see all the changes in migrations that need to or were applied on database in development. Than the person responsible for production rolls out code to production after a full backup is made. However if you don't use a PHP framework that takes care of this than, awied's suggestion sounds very interesting - I haven't heard of liquidbase before but I will definitely check it out.
There is a tool called iBatis, now called MyBatis that handles versions of databases perfectly.
It takes a little work to have all your changes in script instead of with a graphical tool, but, if you are familiar with coding, it's not a problem.
When you have multiple databases (like dev-test-prod), you just make 3 environment files and you can update one environment with only one command-line instruction.
Would you recommend working with multiple programmers on an MS Access application?
One of our MS Access application has grown to the point where the number of changes (bug fixes) and new features can no longer be handled by one programmer in the requested time frame.
We are trying to introduce version control using the undocumented SaveAsText and LoadFromText procedures in VBA to make collaboration on this application possible. Unfortunately we have already run into problems loading modified forms and reports back into Access as a checksum is stored in every form text file.
Before putting time into building an import/export application to compile text files into an Access database, we would like to hear your recommendations.
I think you should avoid this path at all cost, and try and persuade management into redevelopment.
It's a bitter pill to swallow, but this is going to need to be redeveloped sooner or later, and you are just saving them time and money.
We were using Microsoft's own version control add-in for MS Access 2000/2002/2003 for about 5 years now, and I can't remember a single serious problem. Usability of this add-in barely deserves a "B", but it must be much, much more convenient than fiddling with any ad-hoc method involving manual or semi-manual exporting/importing of Access forms, modules, etc.
We were using VSS as a version control system all the time. No problems whatsoever. However, if you have some good reasons to avoid VSS, you may have some options:
The version control add-in that we were using does not require VSS. Theoretically it can be used with any version control system that implements Microsoft Source Code Control Interface (MSCCI). For example, when we had to let somebody work on this project remotely, we used SourceOffsite by SourceGear. Access version control add-in worked with this third-party product fairly well (not without some quirks, but well enough). So, if your favorite version control system complies with MSCCI, you could try to use it.
Now that Microsoft has this Team Foundation thingy, apparently there are other options to be used to integrate MS Access with version control. We did not explore this path, though. This article may be a good start for exploring it.
Hope this would be of some help. :-)
P.S. I am not a big fan of MS Access. In fact, I rather hate it as a platform for a user front-end. If I had a choice, I would run away from it yesterday. :-) However, I must admit that existence of this version control add-in is one of the few things that makes maintenance of our old Access+SQLServer project more or less tolerable. :-))
In addition to what I already said here, I should add that the whole system works very well. The comparison process takes less than 30 minutes a week, for a team of 3 programmers. So let's describe it a little bit.
We have basically 2 versions of our Access program:
The "Developer's version", with all the stuff in it.
We each begin to work with an identical version of our developer's edition. As each one modifies or add parts of the code, we have to run some comparison routine on a regular basis. To do so, we have an object-export routine to a common "comparison" folder. An object (module for example) is exported as a text file (saveAsText command, do not work with tables, see infra), it will be compared to the existing equivalent text files in the folder. If files are identical, there is no file exported. If files are different, the new module is exported with the developer's name as an addition to the file name (if modQueries.txt exists, then modQueries_philippe.txt is created...). Of course if there is no equivalent .txt file in the folder, it will be created at first export.
At the end of the period, we would get in our folder the following files
modQueries.txt, being the first "original", last common version of the module
modQueries_Philippe.txt, with Philippe's modifications
modQueries_Denise.txt, with Denise's modifications
As the module was not modified by other developers, their export did not lead to the creation of a specific modQueries_developersName.txt file
If for any reasons Denise exported many times her module, only the last version is in the comparison folder.
We can then compare (with a "text file" comparer) the different versions and create the "updated" version of the module. We have a screen giving us the number of objects in the comparison folder, number of version for each object, and it is even possible to open the file comparer directly from the developer's interface (We use "File Compare Tool" which has a command-line mode and can then be started directly from Access).
The forms compare issue is quite special, as one of our rules is to have no specific code in our forms (please see here for more details). Forms are then only for display, so usually we do not even compare them. We just make sure that each one of them is updated by only one person (which is quite logical).
The table compare issue (we have local tables) can be only made between mdb files. As we export one text file per module, we also export one mdb file per table. We have a small routine allowing us to identify table differences at the structure level or at the record level.
After each comparison procedure, a subroutine will use all the objects available ini the comparison folder and create a whole new clean mdb file from scratch. This is the new developer's version. Every developer can then copy it on his computer and continue his work.
Developer's versions do not have numbers, but contains last client version number.
The client version, with limited stuff, automatically distributed to users
Each developer has the possibility to build a "client" mdb for final users. This mdb is created from scratch, in a way quite similar to our developer's version, but not all objects are exported. Some specific switches are turned off (special keys, access to code, etc). This mdb holds a version number as a property. The version number is used to build the name of the mdb file.
At production time, this mdb file is zipped and placed in a specific "distribution" folder. Each time a user starts the app, it will automatically check this folder to see if a new version is available. If yes, the client mdb file is updated from the distribution folder, and the app is restarted.
This distribution folder is replicated at night time with our overseas agencies. Users abroad will then be able to install the new version on the following day.
Following the direction provided by Yarik we settled on continuing developing in Access using the Access Add-in Source Code Control, the SVN SCC API Plugin by PushOk Software and Subversion. This stack provides us with seamless Access integration, full-backup and restore and an open version control system.
We had to install a hotfix to Access 2003 and make sure the default database file type matched our database file type to make it work.
We will continue to update this answer with our findings.
Have look at this thread:
How do you use version control with Access development?
Sounds like a terribly painful way to do team development. If you have any options for porting to another environment like VS2008 that would be my recommendation.
There is no easy way to work on Access as a team and even version control might be a bit tricky.
I'm building an install using VS 2003. The install has an Excel workbook and two Access databases. I need to force the Access files to load regardless of the create/mod date of the existing databases on the user's computer. I currently use ORCA to force in a Version number on the two files, but would like to find a simpler, more elegant solution (hand editing a .msi file is not something I see as "best practice".
Is there a way to add a version number to the databases using Access that would then be used in the install?
Is there a better way for me to do this?
#LanceSc
I don't think MsiFileHash table will help here. See this excellent post by Aaron Stebner. Most likely last modified date of Access database on client computer will be different from its creation date. Windows Installer will correctly assume that the file has changed since installation and will not replace it.
The right way to solve this (as question author pointed out) is to set Version field in File table.
Unfortunately setup projects in Visual Studio are very limited. You can create simple VBS script that would modify records in File table (using SQL) but I suggest looking at alternative setup authoring tools instead, such as WiX, InstallShield or Wise. WiX in my opinion is the best.
Since it sounds like you don't have properly versioned resources, have you tried changing the REINSTALLMODE property?
IIRC, in the default value of 'omus', it's the 'o' flag that's only allowing you to install if you have an older version. You may try changing this from 'o' to 'e'. Be warned that this will overwrite missing, older AND equally versioned files.
Manually adding in versions was the wrong way to start, but this should ensure that you don't have to manually bump up the version numbers to get them to install.
Look into Build Events for your project. It may be possible to rev the versions of the files during a build event. [Just don't quote me on that]. I am not sure if you can or not, but that would be the place I would start investigating first.
You should populate the MsiFileHash table for these files. Look at WiFilVer.vbs thtat is part of the Microsoft Platform SDK to see how to do this.
My other suggestion would be to look at WiX instead of Visual Studio 2003 for doing installs. Visual Studio 2003 has very limited MSI support and you can end up spending a lot of time fighting it, rather than getting useful work don.