|
Hi: I'm trying to help my brother who is a Dr. and runs an EHR application that uses a Sybase Database V9. He was using the application fine until they notified him that the application will not be longer supported either by the local rep and the US headquarters. I'm trying to see if I can export his patients data using the Sybase Central Developer downloaded from the SAP site because he is now on the evaluation process to buy another EHR program. The big problem that we have is that the local rep doesn't respond his calls so we can get the DBA password or the DBA account they create for the App and from the USA company that develop the App told him that the password is controlled by the Rep for support purposes. So at this point either the company that develop the software and the rep haven't provide any help. I have try some recommendations founded to Unload database so then I can Upload the data to the new Sybase db version but on the user and password it fails. There's any way that I can connect to the DB or to reset the dba password to its default of sql? Robert |
|
There is no backdoor mechanism for bypassing or resetting the DBA user id and password. Sybase Technical Support may be able to help you if you can prove that you own the data... I do not know what the specifics of the "help" or "proof" are.
Actually, technical support won't be able to help here either - the service is no longer available. We no longer offer "database salvage" services in SAP technical support (which historically required a separate engagement contract outside of a customer's support agreement), which is what this situation is considered.
(30 Dec '13, 09:48)
Jeff Albion
Replies hidden
Seriously? Not even for "enough money"? Well, I surely try to avoid need for such kind of data salvage - however, I have always felt better knowing tech support could help in such (hopefully very rare) cases... Or is there a different SAP support channel for such cases?
(30 Dec '13, 10:23)
Volker Barth
No. The bottom line is that there is no longer a legal framework in place for us to operate such a service in, so we cannot offer this service to customers at this time. From a support perspective, we would much prefer customers to assume they are "on their own" for the responsibility of the integrity of their database and need to have a proper backup and recovery strategy in place. The knowledge that the salvage service existed gave customers the wrong impression about their approach to backups and our general ability in support to recover corrupted databases - we never have guaranteed the ability to recover databases in this situation, so it was very much a 'last ditch' attempt at potentially great cost to the customer.
(30 Dec '13, 10:51)
Jeff Albion
@Jeff: I can surely follow your explanation - and I fully agree on your points of "customer self-responsibility" and the risk of the previous service to be misinterpreted as a "granted vendor backup facility". Nevertheless, I would suggest that SAP should drop a note that such an important "last ditch" service is no longer available (unless I have missed that note by chance...). If I would have required data salvage lately and would only have found a nested comment here on that topic, well, I would not be happy, you see:)
(30 Dec '13, 11:18)
Volker Barth
1
WOW! That is QUITE A DRASTIC thing to learn from an incidental post on this blog.
(30 Dec '13, 11:36)
Bill Aumen
Replies hidden
Guess that's what I have tried to say - with more and less precise words. obviously:)
(30 Dec '13, 11:57)
Volker Barth
Database salvages were previously a Sybase engineering 'contractual engagement', not a true support service (i.e. something that was advertised as a feature as part of a support plan). Since Sybase customers are now being migrated to SAP support plans, there is no current equivalency in the SAP support plan environment for such a contractual engagement directly with engineering. Hence, there is nothing substantial to document to customers from a support perspective as this service was always a separate contracted engagement, "outside of support". The original advertising for the service was usually in the form of somebody posting in the Sybase newsgroups, urging customers to contact support for further details about this option. Since this forum is now "the newsgroup", my posting here is essentially carrying on our "unofficial" tradition of documenting this ability.
Yes, I can appreciate this point - but other than going back and editing every newsgroup response where we mentioned this (which can't happen for technical reasons), there isn't an "official" place to notify customers of this change. Hopefully, this thread (and any future threads dealing with database recovery) will now help get the word out regarding the current database salvage situation.
(30 Dec '13, 12:00)
Jeff Albion
Looks like it would be a great idea to raise a particular question here on its own on that topic to spread the news... - I'm gonna do that next year, it's still time to collect good intentions for 2014:)
(30 Dec '13, 12:15)
Volker Barth
Your point was quite clear, and quite well worded Volker. I just wanted to add my shock. Jeff: your explanation is no doubt quite technically accurate, but "come on now man..." (Deion Sanders), surely, loyal SQLA customers deserve more than this kind of surprise.
(30 Dec '13, 12:31)
Bill Aumen
|
Do you have any database user id and password at all?
Does the application offer any form of "ad hoc reporting" or "extract" facility?
Did it come with the dbisql.exe utility program in the C:\Program Files (x86)\Sybase\SQL Anywhere 9\win32 folder?
Hi Breck:
Thanks for your response. I'm looking to see if there's a user application defined on the database and if someone at the office knows the passwoooooooord!!!!.
I will then look at the application to see if there's any export, ad hoc for reports etc I really appreciate this comment because this could be an alternative.
I will also check if the dbisql.exe is installed but probably the password will still an issue when trying to connect thru sql.
Regarding how to proof probably you are right but by mention to them the EHR Software Name and Company they will recognize it and now the issue because I doubt he is the only one because he mentioned to me that other colleagues also bought the same EHR Software and they still using it but they have the same issue NO SUPPPORT either locally and from the US. Probably they will ask the Dr. some other information just to validate and then ask for remote access or send some instructions on how to do it to the Dr.
Thanks, Robert
Hi Robert,
This is definitely your best bet for extracting this data. Since the data is contained in an OEM vendor's database, the vendor technically has the user data "locked" as there is also potentially intellectual property also stored inside the database (code for functions, events, stored procedures, etc.) that would also need to be "locked." OEM vendors of applications will generally not let users connect directly to the SQL Anywhere database to do data exports because of this reason.
If the vendor no longer supports the user application, then this is unfortunately the end of the support that we would be able to provide for you also. To work with technical support, we generally need to work with the OEM vendor when also working with end-users of the OEM application, as they will know what permissions and restrictions they are using with the database and what options they have allowed to extract data.