Skip to Main Content

ODP.NET

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Cannot uninstall ODP.NET

Lars PedersenApr 18 2018 — edited Apr 19 2018

I am trying to use Oracle Universal Installer to deinstall the two Oracle Homes on my pc.

I think they have become corrupted because I installed Oracle Developer Tools for Visual Studio 2017 in the wrong way (I picked "For beginners" on this page: Oracle .NET Software Downloads ).

However, the Oracle Universal Installer seems to hang at "Deinstalling Oracle Data Provider for .NET 11.2.0.3.0". When I cancel and click Remove again, the installer stays at the same spot.

How can I remove the (probably corrupted) provider?

This post has been answered by Lars Pedersen on Apr 19 2018
Jump to Answer

Comments

John Thorton

3372439 wrote:

When I asked the same they said that showing primary key on UI is not a good practice .

Who are "they"?

Ask them for proof & substantiation to support their claim.

What is downside for showing PK?

BEDE

Still, I think the device should have some unique identifier, other than the ID generated using the sequence. It should have some kind of serial number or so... Otherwise, there is the risk of entering the very same device N times and losing it completely.

GregV

Hi,

I don't see a problem in showing the pk id. Can you ask "them" why it's not a good practice?

mathguy

There are cases when you may want to hide a PK, even if the PK is generated by a sequence. See how close your situation is to these examples. (I don't see, in particular, how such things might apply to id's assigned to devices, not to people or to financial assets.)

1. Personal identification number/code (in the U.S., Social Security Number). At least in some countries, identity theft is a big concern, and the most valuable piece of information for thieves is the PIN (SSN in the U.S.). One might make the case that SSN's are generated by sequence (with a number of rules though). And some databases do use the SSN as primary key. I would not want that PK to appear in the UI, if the UI is to be accessed by users who don't otherwise have access to the PIN/PIC/SSN.

2. Same with bank or brokerage account numbers, mapping to customer id. Right now your users can access information by customer id. They may need to be able to check information from one account (say from the "joint checking account") but they have no business knowing the actual account number. Account numbers, again, are probably generated by sequence. I wouldn't want to expose those numbers to the "general public" (depending on who, exactly, has access to the UI).

GregV

Hi Mathguy,

I think in both your examples these wouldn't be used as PKs. Suppose I make a mistake in entering somebody's SSN or bank account number, then the PK would need to be updated.

John Thorton

3372439 wrote:

Hi All

Presently we get device details though a feed where multiple devices can be mapped to single CustomerId. The device details are loaded in table : TBL_DEVICES . The devices presently do not have any natural primary key so we have created a sequence as primary key . We had a new request to assign a unique key for each device so that they can be searched from the UI using the unique key (Presently they can search using CustomerId) . The team has asked me to create a new column and increment using a sequence .

TBL_DEVICES ( Existing structure)

-----------------

DEVICE_ID NUMBER PRIMARY KEY using Sequence

CUSTOMER_ID NUMBER FOREIGN KEY

DEVICE_DESC VARCHAR2(100)

CAPACITY NUMBER

Can't we use the existing primary key as a unique key? . When I asked the same they said that showing primary key on UI is not a good practice . I was not convinced as it doesn't make sense to add a column and sequence which adds no value.

Please suggest.

Thanks

Implicit in using SEQUENCE as PK, is that only a single record will exist for EVERY device.

In other words can the same physical device have data record in more than 1 file of data to be loaded?

If so how do you plan on associating the multiple device records to the same physical device?

Frank Kulash

Hi,

I don't see any reason to have two sequence-generated unique keys in the same table.  If users are content seeing a numeric serial number in the interface, it might as well be the one you already have.

As John said in reply #1, what is the harm in showing the primary key?  If someone thinks that is a bad ideas, ask them to explain.  You might post their answer here; it could be interesting.

The general rule is that a primary key should not do anything except uniquely identify a row.  If someone can tell, just by looking at a device_Id, how old it is, or where it is located, or who manufactured it, or anything else about the device, then it's probably not a good primary key.  For example, a user should not be able to see device_id = 83 and deduce "It must be an old device; it has a 2-digit number" or "It's in the eastern region, since the last digit is 3". 

mathguy

I didn't mean "you" using my SSN in your own database (if you are my dentist, say). Rather, I mean the Social Security Administration itself, and the various users who feed into and from their database.

Same with the bank - my bank assigns an account number to me, perhaps by sequence, starting from their database and then flowing from there to everywhere else.

I guess your suggestion, in these cases, is that the SSA and the bank are doing it wrong. They should assign a SSN to me (or an account number), and that number should be unique, but such numbers have no business being the PK in their tables. I would agree with that 100%, but I don't control what the bank and the government are doing, in their IT department. If for whatever reason they DID use these sensitive numbers as PK (as they may have, I don't know), then I wouldn't want them to expose this PK.

I think we are pretty much in agreement, I am perhaps just more paranoid than most.     On the other hand, if such idiotic practices were not present in real life, I wonder how we get such huge data breaches seemingly all the time...

John Thorton

mathguy wrote:

There are cases when you may want to hide a PK, even if the PK is generated by a sequence. See how close your situation is to these examples. (I don't see, in particular, how such things might apply to id's assigned to devices, not to people or to financial assets.)

1. Personal identification number/code (in the U.S., Social Security Number). At least in some countries, identity theft is a big concern, and the most valuable piece of information for thieves is the PIN (SSN in the U.S.). One might make the case that SSN's are generated by sequence (with a number of rules though). And some databases do use the SSN as primary key. I would not want that PK to appear in the UI, if the UI is to be accessed by users who don't otherwise have access to the PIN/PIC/SSN.

2. Same with bank or brokerage account numbers, mapping to customer id. Right now your users can access information by customer id. They may need to be able to check information from one account (say from the "joint checking account") but they have no business knowing the actual account number. Account numbers, again, are probably generated by sequence. I wouldn't want to expose those numbers to the "general public" (depending on who, exactly, has access to the UI).

The reality that you desire to NOT display certain data columns has NOTHING to do with the happenstance that they are Primary Keys;

but everything to the sensitive nature of the value itself.

You would avoid displaying the columns mentioned above, even if another column was the Primary Key to the table where they reside.

Some folks "insist" that every table have a Primary Key.

Much more often than not, it is 100% innocuous to display Primary Key.

There are certain situations where displaying PK would be unwise, but that has no real connection these values are Primary Keys per se.

Mark D Powell

GregV, a new bank account number is normally constructed rather than manually entered on creation so I think account numbers may well be a PK.  I have seen SSN used as the PK in several systems though more modern practice is probably to use a surrogate key instead.

- -

ALL, contrary to what people believe SSN are not unique since somewhere between 10K and 40K were reissued by mistake and the article below indicates there were some other issues related to uniqueness.  The SSN can contain a non-numeric digit usually appended to the end of the number.  Such numbers are generally assigned to non-citizens who inherit benefits.

- -

Article on SSN

https://www.ssa.gov/policy/docs/ssb/v69n2/v69n2p55.html

- -

user3372439, I think BEDE and MathGuy gave you good responses.

- -

HTH -- Mark D Powell --

Paul Susanto

Yes, I agree with you, apart from the Primary key column which in certain cases can be simply a sequence generated value, I will recommend from my last experience that is is better to have some other unique field as well.

Regards,

Susanto Paul

mathguy

I agree, in the examples I gave the concern was with privacy and confidentiality. I wouldn't want "the general public" to access my medical history, past political affiliations, or even (for some people) the purchasing habits, any more than my social security number or bank account number. But the distinguishing characteristic of the examples I have is that they are (or may be) generated by sequence, and therefore MAY (even thought they SHOULDN'T) be used as PK. In that sense, "not displaying them" has everything to do with the poster's question, which was about including PK in the UI. No one would think of using my medical history or voting record as PK in a table; so that comparison doesn't make sense in this context.

The more relevant question, I believe, is whether there are similar concerns with publishing the PK values generated by sequence for a bunch of devices, not for human beings - and, even if such concerns may exist (I can't think of any, but I am not engaged in industrial espionage either, or in trying to sabotage efforts of foreign governments or companies - or defending such governments or companies from attacks) - so, even if such concerns may exist in general, whether they apply to our OP.

unknown-7404

The device details are loaded in table : TBL_DEVICES . The devices presently do not have any natural primary key so we have created a sequence as primary key .

Ok - but what prevents the SAME PHYSICAL DEVICE info from being duplicated in that table?

1. add widget #1 name/model/other - gets sequence number 23

2. add widget #1 again using same name/model/other - gets sequence number 37

Those are the SAME device. What prevents 100 or 1000 of that 'same device' from being entered and getting 100 or 1000 different numbers?

That is the FIRST question/problem that needs to be addressed.

We had a new request to assign a unique key for each device so that they can be searched from the UI using the unique key

You already have a 'unique key for each device' - it can be used to search.

BUT - the NEXT question/problem to be addressed is HOW will a user know what unique key they want to search for? Where does the user get the key value to use for a search?

Unless they already know that 'unique number' for the device then typically they might first search the 'device table' to find the device of interest and then use the 'unique number' for that device to search other tables for data. But again - you already have a unique number for each device (the sequence).

Also - if the user has to search the device table to find the device of interest then the second search can just use the results from the first search and the user NEVER needs to know what that 'unique' device number is.

So how does a user know what device number they want to search for? Is it on a piece of paper somewhere? an invoice? payment? other?

The team has asked me to create a new column and increment using a sequence .

You already have one.

Can't we use the existing primary key as a unique key?

Yes - a primary key MUST BE UNIQUE - or it wouldn't be a primary key.

When I asked the same they said that showing primary key on UI is not a good practice .

What does 'showing primary key on UI' have to do with anything? There is NOTHING in what you posted that even discusses what is, or is not, shown on the UI.

You don't have to show a primary key on the UI in order to be able to use a key value to do a search.

The two aren't even related.

You should ONLY show on the UI:

1. info that the current user is entitled to see based on your security requirements

2. info that the current user needs for some business purpose.

Tell us what ALL of the requirements are for a user that wants/needs to do this new 'device search'.

In particular tell us how they are going to know in advance what this new 'unique device number' is no matter HOW you implement it.

Sven W.

It depends.

If the table has a UK aside from the PK, then it is preferable to hide the PK and always show the UK.

The assumption here is, is that the PK is a meaningless technical ID and the UK is some business related value that the user can refer to.

If the table has only a PK, then yes sometimes it makes sense to show that PK to the end user. Altough there is a certain risk that this raises some strange expectations about that ID.

For example I had an application that was essentially an ordering system. The PK for an order was an ID, but there was no real UK. So in the gui the users did see something like "Order Number 12345". This makes sense. However it once happend that the order numbers suddenly jumped by values of 20. Whereus in the past they usually were monoton increasing numbers. And the users complained about that.

Reason had of cause to do with sequence caching (there was an issue with SGA sizing and sequence caches did age out of the SGA too fast). But it shows that even if it is a meaningless technical number, as soon as the users see that value, they start to have expectations about it.

This is something to bear in mind.

AndrewSayer

3372439 wrote:

Hi All

Presently we get device details though a feed where multiple devices can be mapped to single CustomerId. The device details are loaded in table : TBL_DEVICES . The devices presently do not have any natural primary key so we have created a sequence as primary key . We had a new request to assign a unique key for each device so that they can be searched from the UI using the unique key (Presently they can search using CustomerId) . The team has asked me to create a new column and increment using a sequence .

TBL_DEVICES ( Existing structure)

-----------------

DEVICE_ID NUMBER PRIMARY KEY using Sequence

CUSTOMER_ID NUMBER FOREIGN KEY

DEVICE_DESC VARCHAR2(100)

CAPACITY NUMBER

Can't we use the existing primary key as a unique key? . When I asked the same they said that showing primary key on UI is not a good practice . I was not convinced as it doesn't make sense to add a column and sequence which adds no value.

Please suggest.

Thanks

Someone saying something is not good practice with zero justification is not an argument in my book.

You should ask them why.

Mike Kutz

Sven W. wrote:

It depends.

If the table has a UK aside from the PK, then it is preferable to hide the PK and always show the UK.

The assumption here is, is that the PK is a meaningless technical ID and the UK is some business related value that the user can refer to.

If the table has only a PK, then yes sometimes it makes sense to show that PK to the end user. Altough there is a certain risk that this raises some strange expectations about that ID.

For example I had an application that was essentially an ordering system. The PK for an order was an ID, but there was no real UK. So in the gui the users did see something like "Order Number 12345". This makes sense. However it once happend that the order numbers suddenly jumped by values of 20. Whereus in the past they usually were monoton increasing numbers. And the users complained about that.

Reason had of cause to do with sequence caching (there was an issue with SGA sizing and sequence caches did age out of the SGA too fast). But it shows that even if it is a meaningless technical number, as soon as the users see that value, they start to have expectations about it.

This is something to bear in mind.

Worst - The sequences stays monotonic and the end-user uses the expected number instead of the database generated number.  The solution to that problem included usage of DBMS_RANDOM.string().  For data from this table, the PK is hidden to all except the "data manager" pages.

For me, I usually design under the concept of "Under normal conditions, the end-user does not need to see the PK".  For those pages, the PK is hidden by default.  eg The PK column is not part of the Default Report for an APEX IR but it can still be accessed if the end-user chooses to do so.

MK

Badam123

Hi John

I didn't get your question .

But yes , single record will exist for single device and multiple devices can be mapped to single customer.

Badam123

Thanks Frank , I shall check with team and get back

Regarding your example , Could you please elaborate why we shouldn't  have a primarykey which could be seen and understood.

Is there any harm when it is partially explicable (instead of full) ?

Example : CEM12345    

C - California state

E - Eastern region

M - Male

12345 - unique number assigned .

Here in this case the last 5 digits changes for males in the same region . Can we use this as primary key ?

Badam123

Hi Bede

I don't understand how we can lose if entered multiple times

Marwim

A sequential Order ID might be exactly the reason why it should not be displayed. It could give third parties hints about the total sales.

While the german tax office demands a gapless numbering of invoices this is the reason why gapless numbers for each customer are allowed.

Sven W.

Please note that I never mentioned a requirement like gapless numbers. If this is an requirement then a sequence is not the right solution as we all know.

In my case the users never had a problem when the order_id was jumping from time to time. However they expressed concerns when the order number jumped by 20 values each and every time. And they were right to be concerned about it, since there was a technical issue behind that.

My point was that as soon as we start showing ID values (filled from a seqeunce) to end users, they start working with that number. This is not wrong - but it is something to be aware of and to consider upfront. The ID then starts to replace the business UK.

Also hiding ID values to avoid giving third parties information is not a valid security solution. "Security by obscurity"  is not something to aim for (https://en.wikipedia.org/wiki/Security_through_obscurity ):

The National Institute of Standards and Technology (NIST) in the United States specifically recommends against this practice: "System security should not depend on the secrecy of the implementation or its components."[6]

Jarkko Turpeinen

3372439 wrote:

Hi All

Presently we get device details though a feed where multiple devices can be mapped to single CustomerId. The device details are loaded in table : TBL_DEVICES . The devices presently do not have any natural primary key so we have created a sequence as primary key . We had a new request to assign a unique key for each device so that they can be searched from the UI using the unique key (Presently they can search using CustomerId) . The team has asked me to create a new column and increment using a sequence .

TBL_DEVICES ( Existing structure)

-----------------

DEVICE_ID NUMBER PRIMARY KEY using Sequence

CUSTOMER_ID NUMBER FOREIGN KEY

DEVICE_DESC VARCHAR2(100)

CAPACITY NUMBER

Can't we use the existing primary key as a unique key? . When I asked the same they said that showing primary key on UI is not a good practice . I was not convinced as it doesn't make sense to add a column and sequence which adds no value.

Please suggest.

Thanks

I agree with the team. Do not expose primary key (row ID) and let it seem to be business key as a part of business data.

Surrogate primary key has no other domain than keep row unique ID. That has no relation to business. Device must be unique based on its attributes (business key), not by its row ID.

Surrogate keys may change and like rp024 points out, there are possibility to have many rows of same device (by business key) but with totally different PK aka row ID.

Don't give a column multiple meanings is my argument.

Frank Kulash

Hi,

3372439 wrote:

Thanks Frank , I shall check with team and get back

Regarding your example , Could you please elaborate why we shouldn't have a primarykey which could be seen and understood.

I know that's unintuitive.  I had a hard time believing that dictum when I first heard it.  But maintenance is eaisery, and complications are reduced, if the primary key doesn't contain any information (other than uniquely identifying the row).  Here's why:

If you need to update the target of a foreign key, then you need to update all the children in other tables that reference that foreign key.  That's a lot of unnecessary work.

If a column contains any real information, you may need to update it.  For example, if you have a key that identifies location, the location may change, or you may discover the location was entered incorrectly.  So targets of foreign keys should be surrogate keys, that contain no real information.

Primary keys are often targets of foreign keys.  There may not be any foreign keys when you create the table, but applications grow.  When you create something today, you want to design it in a way that any maintenance you may need to do next year (such as adding a foreign key) will be as simple and robust as possible.

Is there any harm when it is partially explicable (instead of full) ?

Example : CEM12345

C - California state

E - Eastern region

M - Male

12345 - unique number assigned .

Here in this case the last 5 digits changes for males in the same region . Can we use this as primary key ?

The same reasons apply if any part of the key contains real information.

The example above has another problem: it has four independent pieces of information in one column.  Relational databases work best when each column of each row contains (at most) one piece of information.  This rule is so basic to database design that it's called First Normal Form.   A better design would have four separate columns (state, region, gender and unique_key).  I will make queries simpler and more efficient when you need to do things like include only certain regions.

If you need to display all the information together in a single string, like 'CEM12345', it's easy to concatenate the values together.

Columns are like atoms.  It's relatively easy to combine atoms into molecules. While it is possible to split atoms apart, it's much harder.

Marwim

I only took the ORDER_ID as an example for data that might tell more than you intend. I didn't say that it should be generated by a sequence.

Also hiding ID values to avoid giving third parties information is not a valid security solution. "Security by obscurity"  is not something to aim for (https://en.wikipedia.org/wiki/Security_through_obscurity ):

The National Institute of Standards and Technology

(NIST) in the United States specifically recommends against this practice: "System security should not depend on the secrecy of the implementation or its components."[6]

If I have to choose between a requirement from German tax office and a NIST recommendation I'm sure what I'll take :-)

Edit: Of course a gapless invoice number should not be the primary key.

The primary key should be generated by a sequence, the invoice number later when the order is confirmed.

Edit 2: And it is not about System Security but business secrets

mathguy

The National Institute of Standards and Technology (NIST) in the United States specifically recommends against this practice: "System security should not depend on the secrecy of the implementation or its components."[6]

The gap between "should not" and "does not" is so big, Arnold Schwarzenegger could drive his Hummer through it.

The issue does not arise (perhaps) in systems that comply with the NIST recommendation. How many systems in real life DON'T comply with it?

More relevant to this thread: How much risk can a new developer joining an existing organization take in this regard? Can they assume that the system they inherited was built in compliance with the NIST recommendation?

unknown-7404

Could you please elaborate why we shouldn't  have a primarykey which could be seen and understood.

I already 'elaborated' extensively on why what can be SEEN has NOTHING to do with whether the value is a primary key or not.

It is ALL about SECURITY and whether the user needs (and is allowed) to see the info to do their job.

If a user either needs to see a data value, or you simply want to allow them to see a data value then put it in the UI and let them see it.

Not sure what is so hard to understand about that.

Is there a SPECIFIC question you have about the above guidelines?

BEDE

That is that you actually may have the same item entered N times and, looking at what is in the table have more items than in real life... So, you "lose it" figuratively speaking because looking at what is in the table you don't have the correct image of what is in real life.

Jonathan Lewis

3372439,

I won't make any comment about the gaps in the model you've described, but I'll offer a hypothesis regarding your company rule on primary keys and UIs.

Sometimes the answer to "Why do you do X?" is "Because 15 years ago we tried doing Y and something broke so we did X as a workaround and now we always do X".

A possible argument for "don't display the primary key on UI screens" is that a common (historic) mechanism for handling updates from UI screens was to generate a single SQL statements that said: "update the row in the database with every column that's on the display screen - whether or not it has changed - based on the rowid". If your screen display includes the primary key then you've just updated the primary key (even if it hasn't changed) so you are at risk of the "foreign key locking" issue unless you've created indexes on every foreign key that relates to that primary key column. Since it can be a huge waste of resources to create massive indexes for cases where the optimizer would never use them it would have made sense to find a way around this UI issue - and an easy option is to have a rule that says "don't display the primary key".

Once enough time has passed there's no-one around that knows why something is done, only that it is done and that it might be dangerous not to do it.

Regards

Jonathan Lewis

Mark D Powell

Jonathan, >> Once enough time has passed there's no-one around that knows why something is done, only that it is done and that it might be dangerous not to do it.  <<

- -

so true. 

- -

user3372439, you have gotten a lot of reasonable responses so I would think you should probably mark this thread as answered using the ACTION link in the upper right of the screen when you are in the thread (rather than in the mail box).

- -

IMHO -- Mark D Powell --

1 - 29
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on May 17 2018
Added on Apr 18 2018
3 comments
1,805 views