I found this article but it doesn't work. It generates the dmp file with 1 kB and downloads the file with 1 KB.
Does anyone have a solution to make the system automatically update (.exe)?
Printable View
I found this article but it doesn't work. It generates the dmp file with 1 kB and downloads the file with 1 KB.
Does anyone have a solution to make the system automatically update (.exe)?
Can you explain what you are trying to do?
An EXE is just a collection of bytes. To dump a collection of bytes in a database table you would use a 'blob'
For using 'blobs' in MySQL: https://www.basedash.com/blog/storin...ge-binary-data
What system? Your application?
I'm not sure how your database figures in this.
This is most often done with a separately-installed installation service or, in very simple cases, using a "bootstrapper" program. The "bootstrapper" is a separate program with the ability to overwrite the existing application (executable) with a new version. What you cannot do is to have a running application update (overwrite) itself.
You'd have to run the application, extract the executable, store it somewhere (hoping that your virus-checker doesn't get upset with it), then launch the "bootstrapper", immediately shut down the main application, allow the "bootstrapper" to overwrite the main application and then restart it (and hope that nothing goes wrong, because then your User has no application at all!).
If anything more than that is required (say, other libraries or controls that might need "Registering" on a Windows box), then you would have to go down the installation service route.
Regards, Phill W.
I think as suggested explain what you are trying to do. Blob is the way to go not varchar
Yep, I'll also vote for a blob field/column. I've stuff all kinds of stuff into blobs in all kinds of databases in the past. As previously stated, everything (including an EXE) on our computers is just bits-and-bytes, and that's precisely what a blob is designed to hold without caring what those bits-bytes represent.
I have a Visual Basic system.
I need to access the client's machine all the time to make updates.
I discovered that it would be possible to place the executable inside the database, so the client could make the update in a practical way.
The only tutorial I found was this one https://osandamalith.com/2016/06/24/...-inside-mysql/ , but it didn't work.
+1
I always create a "release" directory under the root and a launcher exe, it search for the latest exe in /relase (I use just a numerical name) and launch that version (also delete the exes that are not in use if it's a network app). Also have a version that downloads latest version from a url, put it in the release directory, etc. Easy and it works.
This is a very strange requirement.
You absolutely don’t need access to the client’s computer all the time.
And how would storing an update of an application in a database solve this requirement?
Read post #3 by Phill again and study it.
Also you don’t have a Visual Basic System, you have an application developed with Visual Basic
The link you posted is about storing an application in a local mysql database.
A local database will not have an update of your application.
You download an update from a website or other online storage system
I have a system under development. I need to update two clients all the time. I don't have a place on the internet to store the .exe file and do the update.
For this reason, I thought about storing the .exe file inside the Mysql database so that clients can download it.
I already have a module that does the update, first shutting down the main system, downloading it and starting it again. But I don't have anywhere to store these executables.
I had never heard of this "Setup Bootstrap for Visual Basic Setup Toolkit"
It depends. For example you can have an app installed in a network environment with the exe stored in a shared resource so may be the exe is opened in 20 stations more so you will not be able to upgrade anything. If you use a launcher you can check which is the latest version available in the shared resource and load it.
I assume that you have two clients in a network and both connected to a SQL Server database so you have a server (or at least one machine sharing resources with the other). Then you have a shared resource (or you're able to have one) and you can "read" the exe from there, no need to involve the database. And you can have only one exe, no matter if you have two clients or hundreds of them so no need to update every station, just one.
You have a module that does the update but if you don't have anywhere to store the executables that module does...nothing? I mean, you can do exactly what you want, but I've never seen an app (comercial or not) use that way to upgrade the main exe, there are better and easier ways to do that.
Hi everyone,
I use VB6 + MySQL.
The database is on a server exclusively for MySQL, and I don't have space to store files. This is the problem.
My clients are far away from me, so I have to access each machine remotely and do the update.
Then set something up. Use github. Use one drive. Use Google Drive. use SOMETHING, anything BUT a database.
-tg
If you're that tight on space, your database is going to have problems of its own ... and soon.
Databases love to have space to run around in and they get really upset (i.e. stop working) if they run out of it.
You need to discuss this requirement with your clients.
If you need a way to update software on their machines then you need to agree how that should be done.
The client may have all sorts of security requirements that might affect your choice of solution or they might even have a standardised delivery mechanism in place (Service Manager's Configuration Manager product, for example) that you could hook into.
Regards, Phill W.
If you really don't have space forget your original idea because storing a exe in a DB will need more space than if you store it in a standard way.
So I assume that you have space but you don't have a shared resource to store files and as other suggest this is something that should be discussed with your client because...you're app needs it (or store it in Google Drive or whatever free cloud storage).
But, if you still want to put a gun in your head and continue in that way (store the exe in the DB) you can do it, just use a table with a BLOB type field. This example store the exe in the DB (using DAO, but you can use also ADO), not tested, write on the fly:
to extract the exe (if you want the latest you can change the SQL query to get the newest):Code:Dim bytdata() As Byte
dim rs as dao.recordset
dim db as dao.database
Set db= OpenDatabase("", True, False, "odbc;DRIVER={your_driver};SERVER=your_server;DATABASE=your_db;UID=username;PWD=password;OPTION=16427;")
Open "myexefile.exe" For Binary As #1
ReDim bytdata(LOF(1))
Get #1, , bytdata
Close #1
Set rs = DB.OpenRecordset("your_table'", dbOpenDynaset, dbSeeChanges)
rs.addnew
rs.Fields("field_for_exe").AppendChunk bytdata
rs.update
rs.close
db.close
But take a look to all of our posts: this is not a good idea.Code:dim rs as dao.recordset
dim db as dao.database
dim b() as byte
Set DB = OpenDatabase("", True, False, "odbc;DRIVER={your_driver};SERVER=your_server;DATABASE=your_db;UID=username;PWD=password;OPTION=16427;")
Set rs = DB.OpenRecordset("Select field_for_exe From your_table where id = '" & id_of_your_exe & "'", dbOpenSnapshot)
ReDim B(Len(rs("field_for_exe")))
b=rs("field_for_exe")
Open "path_and_exe_name.exe" For Binary As #10
Put #10, , B
Close 10
rs.close
db.close
I am not an advanced programmer and I only know how to program in VB6, so I have my limitations when it comes to finding solutions.
Google Drive and other portals when hosting .exe files do not provide a direct download link. I have not found a solution for this in VB6 yet.
I will try to use your code and report back with the results. Thank you.
Error (3155 - Failed to insert into linked table '???') is occurring in rs.update
Using Windows 10 - 64 bits
{Mysql ODBC 3.51 Driver}
Linked table? Are you connecting to a real server or you're using any intermediate db/server?
Anyway this code is tested (different version of MySQL ODBC since is the oldest I have installed). First of all create a DB and a table. I've used this in the example:
Code to store the exe in the DB:Code:CREATE TABLE IF NOT EXISTS `storage` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`file` longblob NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;
Code to retrieve the latest exe stored in the db and save it to a file:Code:Dim bytdata() As Byte
Dim rs As DAO.Recordset
Dim db As DAO.Database
Set db = OpenDatabase("", True, False, "odbc;DRIVER={MySQL ODBC 5.1 Driver};SERVER=localhost;DATABASE=test;UID=root;PWD=;OPTION=16427;")
Open "c:\temp\myexe.exe" For Binary As #1
ReDim bytdata(LOF(1) - 1)
Get #1, , bytdata
Close #1
Set rs = db.OpenRecordset("storage", dbOpenDynaset)
rs.addnew
rs.Fields("file").AppendChunk bytdata
rs.Update
rs.Close
db.Close
Tested under Win10 and MariaDB 10.4, should be 100% compatible with MySQL.Code:Dim rs As DAO.Recordset
Dim db As DAO.Database
Dim b() As Byte
Set db = OpenDatabase("", True, False, "odbc;DRIVER={MySQL ODBC 5.1 Driver};SERVER=localhost;DATABASE=test;UID=root;PWD=;OPTION=16427;")
Set rs = db.OpenRecordset("Select top 1 file From storage order by id desc", dbOpenSnapshot)
ReDim b(Len(rs("file")))
b = rs("file")
Open "c:\temp\mynewexe.exe" For Binary As #10
Put #10, , b
Close 10
rs.Close
db.Close
I will update the system on the clients today. I will comment on the results here soon. But preliminary tests indicate that everything is ok.
So far, everything is working. Now I have 5 different machines updating the system through the database. Thank you very much for the code.
But before closing the topic, I will soon restructure my system. I will replace the modules with ActiveX.dll, aiming to optimize it.
And then I want to test uploading these DLLs to the database as well. I will comment here soon.
Unless you're using a Manifest, your Dlls will require registering on each machine, and that will require elevated access on the machine, which your application should not have.
Simply copying ActiveX Dlls will [most likely] not be sufficient.
(You might get away with it if you enforce Binary Compatibility on your DLL projects and never change the Dlls interfaces, but that's unlikely, in the long term.)
Regards, Phill W.
You can use ActiveX DLLs without registration and without manifests just fine. Also with Binary Compatibility they can be updated just by Copy/Pasting them on the target machine (you can add new methods to them but not change existing ones unless you also update the main EXE to take them into account).
I haven't tested it yet, but I could leave a .bat file on the client's machine and register the dlls there.
I'm not familiar with this Binary Compatibility, I'll need to study it.
Check in my signature block ... there should be a link to a posting about binary compatibility - Set your VB6 ActiveX Compatibility.
-tg