I'm currently working in Auditing a software we are supposed to start working on February. As part of the source code, we've recevied what seems to be a C file generated from a Pro*C file.
Pro*C files are compiled using the application "proc" into a C file, then you would use gcc to compile it into an actual executable file.
We are having some troubles with the previous owner of the application, and they refuse to provide us so far with the Pro*C file (pc extension).
I'm not sure if it's possible to revert it back from the C file to the Pro*C, using "proc" or any other tools.
Has anyone been able to do so, and if so, how?
Thanks in advance.
There is no decompiler for C to *Proc file. A C file containing SQL statement in it is call an embedded *Proc file, an utility provided by Oracle. Once you translate this embedded file to C by using a proc translator provided by Oracle it turn that *Proc file into a C file which modify these SQL statement with oracle provided library APIs.
Now my advice to you is, find out all the methods/functions in that C file (generated from a *Proc file) and check and understand what they are doing in Oracle database, especially all the database transactions. Once you understood that, just try to create your own C or C++ file by using ODBC driver api provided by Oracle.
Related
Is it possible to create assembly without access to C: drive on server? Suppose have got access to database only.
Is it possible to create assembly from a variable string where we could store DLL file?
CREATE ASSEMBLY MyAssembly FROM #variable_containing_dll
WITH PERMISSION_SET = SAFE;
OK, found it. On the server where the assembly is installed right-click on the assembly, create it and here you are. You get there CREATE ASSEMBLY with the bits ready to move anywhere without DLL file.
The FROM clause can specify a binary literal or a varbinary(MAX) variable containing the assembly bits. SSDT uses a binary literal for assembly deployment rather than a DLL.
Is there a way in sybase where I can select (read) an image or a file from the a server or driver ?
In oracle there is Bfile , it lets me to read an image directly from the driver, how to do that in sybase ?.
You can read/write text files located on the ASE server's host through a proxy table that is mapped to a file.
Unfortunately, there is no way to read a binary file like an image via such a proxy table or otherwise directly from SQL. Some kludges are possible though:
you can use BCP and a format file to read a binary file into an image column (see my Tips & Tricks book below), and you can run this from SQL via xp_cmdshell.
you can use the Java JVM that is embedded in the ASE server to read files and move the content into a table; that will require combined Java and SQL programming. YMMV.
Can someone please help me to understand a simple batch file? Supposedly, this batch file is supposed to pull information from an MS Access database named "Widgets" in preparation for upload to an off-site server. So I am double-clicking on the file on my PC, which pulls data from tables in a database that is physically located on a different PC (local server) in my office. Then it exports to an excel file which is uploaded to an off-site server. Here is the script:
"C:\Program Files\Microsoft Office\Office11\msaccess.exe" "C:\Backup\Widgets.mdb" /X Job_Search_Export_Macro
It doesn't seem to be working - after running it I can see the excel file that it creates. What I can't see is if the off-site server is grabbing the data. What am I doing wrong? I hope I have provided enough background information.
All that batch file does is start MS Access and instruct Access to open the Widgets.mdb* database and run a macro called Job_Search_Export_Macro (/X is a command line switch for msaccess.exe that tells it to invoke the specified macro). The batch file doesn't actually do any of the other stuff you described. It's the macro that's purported to do that, and if it's not working, the problem lies in the macro's VBA code, not the batch file.
Since the question just asks to explain the batch file, I'm posting this as an answer. If you want to resolve the problem, you'll need to provide the macro's code, and add the vba and ms-access tags.
I'm looking to write a command-line program that can execute database scripts against an Oracle server, however the machine the program will be run on may not have an Oracle client installed on it. I also don't want to rely on a language that requires a VM as there's no guarantee that the VM will be installed, so a language like C is preferable for this. Is there a way that I can statically compile/build this program and not have to have the user install the Oracle client on that machine? I'm trying to be as unobtrusive as possible.
Thanks.
My first guess was to use JDBC (type 4 driver) since you do not want a VM based language, it is out of the question.
SO, I think you should take a look at instant client
http://www.oracle.com/technology/tech/oci/instantclient/index.html
(thanks to google)
Situation:
I have a program written in VB6
The source code of the program is not available
It connects to a database using ODBC connection string.
The vendor setup a connection name to the database when the program was first installed 6 years ago
My machine crashed, all the settings are gone!
The program vendor is out of business. Even they don't have the source of the program now.
Question:
Can I find the ODBC connection name in anyway?
You can use Process Explorer to catch the connection string your program is trying to open. You can find almost everything a program is doing, and you can filter what information is captured/displayed.
I'm not sure I've understood. What exactly happens when you try to run the program? Is the problem that the ODBC connection string was lost because the settings were lost when your machine crashed?
If so I would try the following.
Look on a backup for the configuration file of the VB6 program. It may be an INI file.
Do you know what the database is? Is it an Access file (*.MDB), SQL Server, or what? You may be able to recreate the connection string from scratch. You might have problems if you need to supply a password.
Are you still in contact with anyone from the vendor? I'd have thought whoever originally wrote the program would be best able to help, and might be willing to do a couple of days consultancy.
Can't you use a decompiler?
You can probably run an ODBC trace and then look in the log file to see what the attempted name was. Run odbcad32.exe and go to the trace tab and turn it on. Run your app and then look in the log file (probably at the SQLConnect call).