I am not sure what to make of this weird behavior with generating UUID values. I know uuid_generate_v1() is not as secure as uuid_generate_v4().
We are executing uuid_generate_v1() inside a function to generate a unique Id. Initially when the function was created, it was returning all segments of the uuid populated. I recently needed to create another Azure PostgreSQL instance and was verifying the output and noticed that the last segment of the uuid is now zeros. I re-verified the other Azure PostgreSQL instance we have and they too are now returning the trailing zeroes.
uuid_generate_v4() works fine on all the instances.
I have a version of PostgreSQL 9.6 installed in a docker container on my laptop and it returns all segments populated.
uuid_id
9945111c-b305-11e9-aec6-977857a8b0e6
be647cc2-7cbd-11e9-8498-e7d5a16a0cec
fa1ee220-bf8e-11e9-8b75-000000000000
I am thinking maybe an update was performed, i am not sure where i would check that though.
Hopefully someone might have come across this situation.
Missing MAC address
fa1ee220-bf8e-11e9-8b75-000000000000
That hex string represents the 128 bits of a UUID. Those last twelve hex characters are for the 48-bit node id. For Version 1 UUIDs, node id means the MAC address of the machine generating the UUID.
Most of the other hex characters represent (a) the bits for the value of the current date and time, and the remaining few bits represent (b) a small arbitrary number, and (c) the variant and version of UUID. Those three sources of data are readily available, so no problem there, thus you see the first four segments filled-in.
Likely a bug with Azure
So I would guess you are seeing a bug with regard to Azure failing to report a MAC address for its virtual machines hosting the database.
You are not seeing a problem with Version 4 UUIDs because that version does not use a MAC address. Version 4 uses randomly-generated bits instead, 122 of the 128 bits being random.
You are not seeing a problem on your laptop because your computer (or your Docker container) is properly reporting its MAC address to the Postgres plugin that generates the UUID values.
I suggest you report your experience to the Azure staff as a bug. The Azure folks may not consider it a bug; they might purposely choose to not disclose the MAC address of their server for the security reasons you alluded to in your Question.
I doubt the problem lies with Postgres, the Postgres plugin uuid-ossp, or the well-worn OSSP uuid library contained within the plugin.
Workaround
You might try using a special variation on Version 1 UUID offered by the OSSP library: uuid_generate_v1mc(). This uses a random multicast MAC address instead of the real MAC address of the host computer.
Tip: For testing/debugging, you can simply execute SELECT uuid_generate_v1() ;. No need save to rows and retrieve.
Related
I am trying to open an MS Access database in Base using the instructions here . (I've tried both .mdb and .accdb)
I can follow the process described by Gord with no problems until the last step, where it asks me to save the database in LibreOffice format. I choose a filename (say mylinuxdb.odb), click OK, and then Base opens with this error:
The connection to the data source "mylinuxdb" could not be established.
org/apache/commons/logging/LogFactory
Note that it is complaining about the new .odb database, not the MS Access database. Nonetheless, no data is imported.
Can anyone help with this?
Thank you.
Revised answer:
It appears that this issue is specific to distributions like Linux Mint that install LibreOffice Base by default. Presumably in order to enable embedded HSQLDB databases they also install a rather old version of HSQLDB which conflicts with UCanAccess. To fix that, remove LibreOffice's copy of HSQLDB. For Linux Mint that would be
sudo apt remove libhsqldb1.8.0-java
(original answer)
I was able to reproduce your issue with LibreOffice 6.4.6.2 on Xubuntu 20.04. It looks like the setup instructions on Ask Ubuntu may need to be tweaked.
In the meantime try opening your .odb file, clicking through any errors. When Base opens, choose
Edit > Database > Properties …
and notice that the "Database URL" text box has "jdbc:" in front of it.
so if the textbox contains
jdbc:ucanaccess:///home/gord/Documents/Database1.accdb
then apparently Base will try to use
jdbc:jdbc:ucanaccess:///home/gord/Documents/Database1.accdb
and that won't work. We need to have just
ucanaccess:///home/gord/Documents/Database1.accdb
in the text box (as in the screenshot above).
This is NOT (as per chosen answer) "specific to distributions like Linux Mint that install LibreOffice Base by default". Such statements should be avoided as they are clearly very difficult to prove except with rigorous analysis of all other situations, which is clear was not done and in practical terms cannot be done.
I just encountered this message with an LO Base form which uses a MariaDB installation on Windows 10, using a JDBC connection with the mysql-connector-java-8.0.28.jar connector .jar. The form was created only minutes previously.
Interestingly, I happened to have a Python application running at the same time but, and I stress, this Python application does not use any kind of connection to any mysql database whatsoever. Nor, being CPython, does it use Java in any way whatsoever.
I find that when I close the Python application I am then able to open the LO Base form. Furthermore, after having first opened the LO Base form I am then able to run the Python application.
As to why this ludicrous error should arise in these circumstances in the first place, I do not yet know. Chalk it down to yet one more LO anomaly and oddity around which you have to navigate by hook or by crook.
I have old Progress database. and I want to read an old Progress .db file.
How can I do it?
Progress version year is 1994. 16 bit.
It was running Novell netware but now it is finish.
Please help.
You need to have the Progress executables that go with whatever release of Progress you have that is also on a compatible platform (DOS or Novell would work). I believe that the last Novell release was Progress version 6. (The current release of Progress is OpenEdge 11.)
If you have the executables still on a PC associated with that system then you should be able to access the db. However, if the database is associated with an application and the application was distributed without source code you probably only have a runtime license. Which probably means that you cannot easily extract the data.
If you have access to more recent copies of Progress you could also try converting and updating the db to something more up to date. But that will also be non-trivial as there have been significant architectural changes in the last 25 years.
The files are binary and the format is proprietary. You cannot just read them in an editor. That software also pre-dates things like ODBC by a decade or so -- so you won't find any relief that way either.
Your best bet is probably to find a consultant who has a fully capable copy of v6 who is willing to do the work.
How do I determine the Remote Desktop Protocol version supported by a particular client?
Note that I am NOT asking for the ActiveX control version but the underlying protocol version. As examples from two machines I checked using Help->About (or just About in the case of Windows XP):
On Windows 8, I do NOT want 6.2.9200, I want 8.0.
On Windows XP, I do NOT want 6.0.6001, I want 6.1.
And I am not asking for the protocol version in use in a given session (which is what Determine Remote Desktop Protocol version programatically? is referring to) because we're not in a session, we are validating a client's configuration.
Thanks!
I eventually contact Microsoft about this question and the (somewhat amazing) answer I got back is as follows:
That string is hard-coded and not retrieved from the server or AX (in
fact mstsc.exe checks the build number of mstsax.dll before loading it
to make sure it is consistent with its own build number).
So I guess I will need to fall back on hard-coded OS version information - perhaps the mstsc.exe version. That's yucky but I don't see what choice I have.
I'm installing my driver using dpinst.exe. But before installing my driver I wish to delete all the oem files from inf directory corresponding to my hardware ID.
I want to do this programatically. Please suggest me a way to do this.
**Update :**
I want to do this without device connected as I may pre-install the driver before connecting the device. My device is PNP device.
Use SetupDiEnumDeviceInfo and SetupDiGetDeviceRegistryProperty to match your hardware ID
Use SetupDiOpenDevRegKey and RegQueryValueEx to read the corresponding InfPath
Call SetupUninstallOEMInf
PhilMY has already posted an excellent answer, which is still relevant. However, it is more than ten years old now, so I wanted to update it with more recent/recommended APIs:
Use SetupDiEnumDeviceInfo() and SetupDiGetDeviceRegistryProperty() to match your hardware ID
To get the OEM INF path, SetupDiGetDriverInfoDetail() can be used instead of reading the registry directly
Call DiUninstallDriver() on the resulting INF path (Microsoft recommends using it instead of SetupUninstallOEMInf(). In addition, it returns the needReboot flag, which may be useful in some scenarios.)
#2 is a little tricky as it requires SP_DRVINFO_DATA on input. To acquire it, one typically needs to call SetupDiBuildDriverInfoList() and SetupDiEnumDriverInfo() to iterate through all installed drivers for a particular device (use SPDIT_COMPATDRIVER flag to enumerate 3rd-party drivers).
It has a significant advantage in scenarios when multiple drivers are suitable for the given device, and this approach allows one to choose exactly which driver to uninstall.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Is there some uniqueID of each computer, to differentiate one from other?
For issuing licenses for a certain computer, what would be a good way to determine a unique, globally distinct computer (they will always run windows if that matters) based on their hardware.
There are already some answers to this question on stackoverflow but I have tested all the approaches across a wide range of computers and none of them really work.
What are common approaches to such hardware identification? How might Windows do it?
Here is what I tested using WMI:
CPU-ID as suggested here
It is the same to two identical computers
Harddrive Volumne-ID as suggested here or here
It is the same on a cloned drive (tested with Acronis TrueImage) image
Windows OS serial key
It is the same on a cloned drive image.
Motherboard serialnumer as suggested here
I have found some PCs where WMI does not return a serial number at all
Maybe WMI is not the right tool for the job? Is there another API somewhere out there that lest my query hardare details?
This article describes how to create a Machine Universally Unique Identifier:
Creating a MachineGUID
One solution would be to combine as many of this ID's into one ID that has a much lower rate of being a duplicate:
CPU ID is unique to each processor type - can not be changed
Motherboard Serial Number is unique - can not be changed
MAC address(48 bit) should be unique but collisions can occur - can be changed
Harddrive serial should be unique but for each individual manufacturer - can be changed