I'm using Visual Basic 2010 to build a Windows application, using an Access *.mdb for it's memory. Most of the data reads and writes work correctly, except for where I'm entering data into a datagridview, and using a table adapter update to save the data to the memory via a dataset data source. Again, that works fine until I get to 9 significant figures, and I start to loose precision, for example, 1,033,241.78 saves as 1,033,241.75.
Where I use an oledb connection, I get no such precision loss; 1,033,241.78 saves as 1,033,241.78.
The numeric fields of the database are double, the numeric fields of the dataset are double, so according to all of the best search results, I should be no-where near my precision limit.
Please, any clues?
Related
I have a database where I store MAC addresses. There is quite some discussion about how to store a MAC address in a MySQL database, I decided to store it as an unsigned BIGINT to save a few bytes per row and achieve faster searches.
This would work well, except that when I retrieve an entity from the table the mac address in the entity is limited to 2147483647, e.i. the PHP MAX_INT value for a 32 bit system. So the mac address will not be correct if it exceeds 2147483647 (which will happen for 99% of addresses).
It seems that somewhere in the process from database to entity the value is parsed as int, which breaks the values.
Is there some way of avoiding this? Would it be possible to force the entity property to be a string instead of int?
Similar question that didn't receive an answer: Cakephp 3 Bigint issue - Not receiving the same contact number
It seems the PHP deployment on my Windows 10 laptop runs in 32 bit. A solution would trying to make my PHP + Apache (XAMPP) run in 64 bit, but I would rather have a general solution.
The conversion happens in the type layer (\Cake\Database\Type), it's triggered by the query object when it fetches rows.
By default big integers are mapped to the \Cake\Database\Type\IntegerType. If you need to run this on a 32-bit system, then you could for example remap the biginteger type to \Cake\Database\Type\StringType. In your config/bootstrap.php:
Type::map('biginteger', \Cake\Database\Type\StringType::class);
See also
Cookbook > Database Access & ORM > Database Basics > Adding Custom Types
I'm receiving IEEE754 32-bit floating point data from a remote system and storing it in a MySQL (MariaDB) database. I'm trying to ensure that I can retrieve the data from the database exactly as it was received, so ideally I would be able to insert the binary data directly (to avoid any rounding errors).
Since MySQL uses IEEE754 for floats, I'm wondering if there is any way to work with the binary data directly, or do I have to store data as binary data and convert it outside of MySQL (or store two copies of the data, one in a binary column and one as float column)?
I'm migrating an Access project in which there is a division operating with a date value, the problem is that the table where the value must be inserted is Float type.
Given that Access and SQL Server return different results while operating the division or conversion to float, I need to know what is the math operation to create a function in SQL Server to mimic the Access conversion to double.
For example, the following conversion in MS Access.
Select CDbl(#12/31/2016#);
Results in 42735.
While the equivalent in SQL Server
declare #ADate DateTime;
Set #ADate = '20161231'
select CONVERT(float, #ADate);
Results in 42733
The actual code I'm trying to migrate includes the following syntax:
Select (NumericField - DateField)/30 From ATable;
Is there a reason why someone could divide a date by 30?, as you might know, when MSAccess operates with adding/subtracting would add/subtract days to the date, so if there were a default for dividing I wouldn't have to operate with the underlying storage of the Access date.
I have converted from a MySQL database to Postgres. During the conversion, the picture column in Postgres was created as bytea.
This Xojo code works in MySQL but not Postgres.
Dim mImage as Picture
mImage = rs.Field("Picture").PictureValue
Any ideas?
I don't know about this particular issue, but here's what you can do to find out yourself, perhaps:
Pictures are stored as BLOBs in the database. Now, this means that the column must also be declared as BLOB (or a similar binary type). If it was accidentally marked as TEXT, this would work as long as the database does not get exported by other means. I.e, as long as only your Xojo code reads and writes to the record, using the PictureValue functions, that takes care of keeping the data in BLOB form. But if you'd then convert to another database, the BLOB data would be read as text, and in that process it might get mangled.
So, it may be relevant to let us know how you converted the DB. Did you perform a export as SQL commands and then imported it into Postgres by running these commands again? Do you still have the export file? If so, find a record with picture data in it and see if that data is starting with: x' and then contains hex byte code, e.g. x'45FE1200... and so on. If it doesn't, that's another indicator for my suspicion.
So, check the type of the Picture column in your old DB first. If that specifies a binary data type, then the above probably does not apply.
Next, you can look at the actualy binary data that Xojo reads. To do that, get the BlobValue instead of the PictureValue, and store that in a MemoryBlock. Do the same for a single picture, both with the old and the new database. The memoryblock should contain the same bytes. If not, that would suggest that the data was not transferred correctly. Why? Well, that depends on how you converted it.
I have linked an IBM informix database table through an ODBC connection to an Access 2010 database. My issue is that the date field in this table only shows dd/mm/yy HH:nn:ss in the Access view, where the stored data is to 1000th of a second.
I can show this in Excel 2010 but not in Access 2010: is this possible? Not having this level of accuracy is preventing me making accurate calculations!
There is a similar question on another forum here. The Date/Time field type in Access does not store fractions of seconds, and linked tables implicitly cast their columns to the corresponding Access data type, so the fractions of seconds are not available in a linked table even though they are stored in the remote database.
For example, I have a SQL Server database with a table named dbo.linkedTable that has a datetime column with fractions of seconds:
If I create a linked table in Access the [datetimeCol] is mapped to the Date/Time field type in Access and the times are rounded to the nearest second
As a workaround, I can create a Pass-Through query that uses T-SQL to convert the datetime value to a string...
SELECT ID, CONVERT(varchar, datetimeCol, 21) AS strDatetime FROM dbo.linkedTable
...returning...
...and I can parse the [strDatetime] string value to retrieve the fractional seconds.