I want to compress MySQL result or string inside MySQL query and the result will send to delphi application. I use this to speed up connectivity.
The problem is how to uncompress string from MySQL result inside delphi.
Here is my sample query
Select Compress(AColumn), Compress(BColumn) from ATable
Compress is for storage
The compress keyword in MySQL is not meant to reduce network traffic, but rather to reduce storage requirements.
The details of the compression are not documented and may vary from server to server.
COMPRESS(string_to_compress)
Compresses a string and returns the result as a binary string. This function requires MySQL to have been compiled with a compression library such as zlib. Otherwise, the return value is always NULL. The compressed string can be uncompressed with UNCOMPRESS().
Note that the ability to uncompress depends on the compression library that your MySQL version was compiled with.
Modify the connection string if you want network compression
If you want to compress the network data you specify this in the connection settings:
Add the following string to the Properties property.
UseCompression = true;
A list of all connection properties can be found here:
https://www.connectionstrings.com/mysql/
More info can be found here: http://dev.mysql.com/doc/refman/5.0/es/connector-net-examples-mysqlconnection.html#connector-net-examples-mysqlconnection-connectionstring
(note that this info is quite old, but I'm tweaking the url for the newer versions results in a 404 page not found error).
Note that in Delphi the connectionstring is largly filed in by the properties:
- Database
- Port
- Password
etc
In the Properties property you only supply those ConnectionString options that Delphi does not already cover in its other properties. Multiple arguments are separated by a ;.
Further complications
Different component packs use different names for the extra data you can put into the ConnectionString.
ZEOS calls it properties
Other people call it other things.
Related
Can MyBatis log the complete SQL that can run directly
In general case the answer is NO.
If the query has parameters mybatis can't to that even in principle. In order to log the query all parameters should be serialized and represented as strings. For simple data types like String or Integer this is not a problem but for more complex like Timestamp or Blob representation may depend on the database.
When query is executed there's no need to convert parameters to strings because JDBC driver passes them to the database in more efficient (and database dependent) format. But for logging purposes mybatis has only java objects and mybatis does not know how to represent them as database specific string literals.
So the best you can have (and this is supported in mybatis) is to log the query with placeholders and log parameters used separately. Configure DEBUG log level for the logger named after the mapper.
For log4j configuration looks like this:
log4j.logger.my.org.myapp.SomeMapper=DEBUG
If you are in the development environment and use IntelliJ, I think plugin Mybatis Log Plugin can help you.
And if it is in a production environment, you can copy the log and paste it locally. Then use the plugin feature Restore Sql from Selection or Restore Sql from text(new version coming soon)
Detailed introduction:
https://github.com/kookob/mybatis-log-plugin
you can copy com.mysql.cj.jdbc.PreparedStatement to your project directory(keep the same package path) and call log.info(asSql()) method into after PreparedStatement.execute.fillSendPacket. (while using batch operations you can use executeBatchInternal).
Class will be loaded from your project and the origin class will be ignored, you can try this on other framewokrk and database.
Source has Unicode data but I am using MySQL 64 bit ODBC ANSI driver which is throwing an error after partial load (Errors out after it comes across few special characters) .
Is there any work around for this (other than switching to Unicode Driver)?
SSIS is very stringent with meta data requirements. You have two choices: switch drivers or re-encode the source data to ANSI.
There is a third choice: extract the UNICODE data to a CSV file and then load the file via a Flat File Connection. From there, you can instruct the connection manager to use ANSI or UNICODE.
I implement a more scalable method via flat file imports by allowing for conversion of any encoding that is support by .NET via a PowerShell script (digitally signed of course). In this case, the data provider can throw anything at me and I can encode it to ANSI before loading it.
The solution really depends on what the current and potential future data requirements are. I hope this help.
Update:
I am not a MySQL expert as I do not dev on it. If you are using native conversion functions within the server, you might want to understand fully how it handles conversion of varchar and nvarchar strings when going from UNICODE to ANSI. Again, I turn over the re-encoding to .NET as opposed to server functions.
https://stackoverflow.com/questions/32367311/convert-to-ascii-char-in-sql-server
https://dev.mysql.com/doc/refman/8.0/en/cast-functions.html
https://dev.mysql.com/doc/refman/8.0/en/cast-functions.html
This worked: CONVERT(columnName USING ASCII) as columnName
I have been looking and looking on how to connect a Golang application to a MySQL database (I am using the MyMySQL library with the database/sql interface). If I use the none native version not the database/sql interface I can get the connection to work perfectly and perform queries. If I try to connect using the database/sql go interface (which I think is the best way to interface to MySQL?) then I just cannot get the connection to work? The error I keep getting is 'Wrong database part of URI'?????
Sorry for the variable names but I have been trying and trying to get various versions working so the names are a bit screwy sorry again.
I am grateful for any help understanding my problem, thanks again for your time.
The mymysql package defines a non-standard URI format for accessing MySQL when using the database/sql package (from their readme):
[PROTOCOL_SPECIFIC*]DBNAME/USER/PASSWD
So in your case you'd want to change your format string to this:
connectionStr := fmt.Sprintf("tcp:%s:3306,%s/%s/%s", database, dbname, user, password)
The reason you are seeing the error you are seeing is that the Open function splits the URI into 3 parts based on / (see this) and fails if it finds less than three parts.
On a side note, unless you have a strong reason for choosing mymysql you should consider using go-sql-driver/mysql as it is an excellent MySQL driver and supports standard MySQL DSNs like you already have defined.
Fairly simple question that I can't remember. We have three environments: Local machine (unique for each developer), Development, and Production. Connection Strings are in a config file (not web.config, but web.config points to the file); only one is active at a given time (the other two are commented out; all three have the same name but different values for each environment).
I'm using a rudimentary version of the ActiveRecord pattern to handle data access (i.e. static GetByProperty methods in the Linq-generated CS file). To ensure that all of us can use the Linq classes without having to muck about with the designer, all I would have to do is pass in that configuration setting with the connection string (e.g. ConfigurationManager.AppSetting["TheConnectionString"]) when I new up the DataContext, correct? I am going the approach of newing up a context per request; is there any issue (other than DRY, as I'd be repeating the whole connection string every method) I should be aware of passing the connection string in every time, or is that standard operating procedure?
You chose two of my least favorite things (ActiveRecord and LINQ to SQL). ;-) Regardless, you can move the code to a factory method (or similar) to avoid the DRY issue, if that particularly bugs you. You will likely have to do a small bit of refactoring and re-architecting, but you can solve that issue later.
As for changing connection strings to be environment specific, that is fairly standard operating procedure, whether you are using LINQ, DataSets, EF, or otherwise. Location of the actual persistant store is a configuration issue.
With my source in Subversion, I am having issues when 2 different computers have different connection strings.
The LINQ to SQL designer seems to only like having the same connection string.
Is it possible for the designer to use a connection string that varies since developers have different local configurations, but the actual usage in the web application pulls from the web.config?
Unfortunately, this is a huge source of pain with the LINQ to SQL designer. I do not know of a way to force visual studio to never add a default connection string when you drag tables or stored procedures onto the design surface.
We work around the issue thusly:
we never save our dev passwords
we never use the default connection string in code when newing up a DataContext
we can therefore "safely" ignore the multiple connection strings during sprints that touch the data layer
when things die down/become more stable, we delete the connection strings from the data context, either using properties of the designer surface itself or by editing the XML. At that point, it's up to the modifier of the data context to keep up with deleting the default connection strings.
Alas, this is not an ideal situation. Hopefully VS2010 will "fix" this issue.
I ran into this problem and found your question. Here's the solution we're now using:
Use a centralised Configuration class for retrieving config values from a particular location on the file system. This allows every machine where the code is running to use its own config values.
Create a partial class for the LINQ to SQL data context. Add a custom constructor that takes no parameters and retrieves the database connection string from the Configuration class described above.
For example:
public partial class MyCustomDBDataContext
{
public MyCustomDBDataContext() :
base(Configuration.GetDatabaseConnectionString())
{
}
}
This should now solve the problem both for developers and when deployed to test and production.
By following the guidelines on How Do I? Change Connection String of datacontext default constructor from web.config my application now uses different connectionstrings depending on if HttpContext.Current.Request is local or not.
//using System.Web.Configuration;
partial void OnCreated()
{
//Change this condition to your needs
var isLocal = HttpContext.Current.Request.IsLocal;
this.Connection.ConnectionString = WebConfigurationManager.ConnectionStrings[isLocal ? "localConnectionstring" : "otherConnectionstring"].ToString();
}