I have an exe written in Delphi a decade or more ago, with no source code. It calls a ms sql database, maybe more than 1 to retrieve data. I have read only access to one of the databases, I don't have rights to run sql profiler on it.
Is there a way to get the sql calls that are being made like how fiddler does it for http requests. I'm hoping that there is an app that I can run.
Thank you.
Older versions of Delphi store string properties inside the executable file, at the end of the file.
If the developers did not take action to obscure this, than chances are you can retrieve them there.
It is not always easy to read though, I opened an old delphi program here and searched for the text "select distinct" and this is what came up
some more queries I found, they are there but as I said, not easy to read.
Related
We need to be able to install an assembly to a remote SQL Server database during an MSI installation. In order to do this, we have a SQL script with a replacement tag where the assembly data (hex encoded with the 0x prefix) should go. Now I need to figure out how to make a custom action read the binary file data for the assembly from the MSI file, and put the hex content into a property that InstallShield's "SQL Scripts" action can substitute into the SQL script.
I'm stuck at the point where I need to read the binary file data from the MSI file. I could wait until the deferred context to read the file data from the file system after it's installed, but that doesn't seem to be the way MSI "wants" to operate seeing as how it makes accessing properties so difficult in the deferred action context. I'm not even sure I would still be able to modify the SQL script at that point - it would probably be too late. I think the "right" way to do this is to have the SQL script that will be executed already determined before the deferred action phase begins.
I'm looking for a solution better than my backup plan of having the build process replace the content in the SQL script at build time (because that means we essentially deliver two copies of the file, one for reference/maintenance purposes, and the other included in SQL script).
So how can I read the binary content of a file that MSI will install from a custom action, or is there a better way to install an assembly for a CLR to a remote SQL server?
I would recommend doing what you are trying to avoid doing ;-), and that is having the build process create the SQL script with the CREATE ASSEMBLY [name] FROM 0x.... in it.
I'm looking for a solution better than my backup plan of having the build process replace the content in the SQL script at build time (because that means we essentially deliver two copies of the file, one for reference/maintenance purposes, and the other included in SQL script).
I disagree with the conclusion here. You only need the script with the FROM 0x.... in it. You do not need to keep one that references a path to a DLL. That is not very portable, even outside of the MSI installer scenario. From an SDLC ("Software Development Life Cycle" for those wondering about that acronym) perspective, it is best to have a release script that is self-contained: no external dependency on a DLL somewhere on the file system. And from a "reference" perspective, there is not much benefit to having the DLL outside of possibly viewing its code using ILSpy or Red Gate's .NET Reflector, and that would just be to verify what was "shipped" since you have the actual source code.
The only times I ever bother with the DLL is for demos, presentations, and articles. When it comes to integrating something into a build process, I just read the DLL into a string of hex codes, broken at every Nth character with a back-slash (\) as the final character of the line since that is the T-SQL line-continuation character. An example of this is the following SQL script on Pastebin.com:
SQLCLR Meta-data function for cross-database IndexName()
That script installs an Assembly and creates a Function as a working example of the code I posted in this DBA.StackExchange answer:
Central stored procedure to execute in calling database context
I think I have a blog article somewhere around here on this topic.
I've written a lot of installers with database requirements and I've pretty much come to the conclusion to not try to execute scripts against a remote database. There are just too many things that can go wrong and the MSI's understanding of "installed" just gets out of sync when it's another machine or machines.
There have been times when I just decided to break the database feature out into it's own MSI and run it directly on the data tier server. Now the application tier merely gets the connection string, validates the compatibility and configures the app to use it.
Just a thought.
I've a project that uses EF4 on the client side to talk to a SQL Server db. On that DB there's a bunch of SPs that do operations on records and return subsets of records. Nothing particularly major, about the most intensive bit is generating a few bytes of random data and overwriting part of a byte array with it. The records have to stay on the server for security reasons because the data array's akin to a private key.
In the past I've used ADO for DB access within the SPs, but that seems horribly outdated and clunky compared with EF4. And now that I've updated to SQL Server 2012 which has .NET4 available for SQLCLR stuff, I'd like to do the next SP using EF4 and shift to using that in the future.
Problem is, nobody seems to do it yet and I'm not sure it's possible yet.
I know I could do this by writing a seperate server-side app and having that talk to the the DB on my behalf, but that means the client side needs a connection both to the database and to the helper service. More things to get working, more things to go wrong, and aesthetically displeasing.
I've created a simple assembly that uses EF4 to give access to a couple of standard tables. No extra references added. On importing that into SQL Server, I get errors that it can't find "System.Data.Entity" and "System.Runtime.Serialization". Ok, I copy them into the same directory and import again. I get a couple of warnings that I'm in uncharted territory, which is fine for experimenting. But then I get a missing assembly "smdiagnostics". And I can't find any file on the drive that has "smdiagnostics" in the name, a full text search through the project for that term gives no hits, and I've not found much elsewhere that's helped me track down where this can be found.
So does anyone know how I can either satisfy or remove the requirement for smdiagnostics?
Ah. Bit of a "doh". Copying individual assemblies into the same directory as my own DLL isn't the way to go, just a knee jerk reaction to seeing an error message about the referenced assembles not being found even after looking in the same directory.
Assuming the use of the 32 bit server, having selected your own db and having already set trustworthy on, this registers everything needed in order to add an EF4 project;
CREATE ASSEMBLY [System.Data.Entity]
from 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Data.Entity.dll'
with permission_set = UNSAFE;
I've got a linux server that already connects happily to a MS SQL Server and I want to know if there is a way to dump the whole thing into a format I can read. I don't have access to the desktop, but I can connect using PHP and I can issue whatever commands I want. I have admin access to the SQL Server, so no problem there.
My main goal is to understand how the people before me set this thing up. I already know how to get the stored procedures as text (SELECT * FROM sys.procedures), but I was wondering if there is a way to get the whole database. I'm not very familiar with SQL Server so I don't know what important bits I might be missing.
And I don't care if the solution is in PHP or not. That's just the thing I've got working right now. Any SQL-ish command that dumps the entire database would solve my world.
To summarize:
I don't have access to the actual machine/desktop
I have admin access to the DB using PHP's mssql libs
I'm on linux
I want a text file I can look at that tells me everything in the database
My goal is not to answer a specific question - I'm looking to understand what the people before me did when they set up this database. Unknown unknowns, and all that.
Okay, hopefully I've made sense. I'm sorry if I've been a complete idiot. Be gentle. Thanks!
I would backup (http://msdn.microsoft.com/en-us/library/ms186865.aspx) the database to file and then download it, restore it on Windows and then use SQL Server tools like SQL Server Management Studio etc. to look at it.
There is plenty you can do with the metadata, but you could spend a lot of time writing queries instead of using existing off-the-shelf documentation tools.
You can use this script to create insert statements for any given table.
This stackoverflow question will tell you how to generate create table statements.
SELECT NAME FROM sys.tables will give you a list of table names.
You would probably save a LOT of time and pain by just using native SQL SErver Windows tools that work with it.
I have an old compiled Access Application mde file. This application has linked tables to network shared folder. I tried to upgrade main database using upsizing wizard on main database and everything went well. Then when the application starts it gives error message that
Microsoft jet database engine cannot find the input table or query table
I have checked the shared mdb file it has exact table names and everything.
Then I called the guy who developed this application. He said I have to rewrite the application to not use Jet engine...
What does Jet Engine has to do with linking tables? Do I really have to rewrite the whole application to use ADO?
Many questions:
do you have the source MDB file? I can't recall if creating an MDE fails if the linked tables are not correctly connected. In any event, should you end up needing to alter the app, you're going to need the source MDB file.
the error message you report should give the name of the missing table.
do you know when the error is being reported? There could be any number of places where simply replacing tables linked to a Jet MDB back end with ODBC links to a server will not fix things. For instance, should there be any saved queries or SQL in code that bypasses linked tables and uses a direct connection string, that could produce an error like you see.
in regard to the developer's response that "I have to rewrite the application to not use Jet engine..." either you misunderstood what he said, or your developer is completely incompetent. Or both, I guess. Jet works very well with ODBC linked tables and if you're using an MDB front end, it is impossible to completely eliminate Jet, as the MDB is a Jet data file. The desire to eliminate Jet mostly comes from people who can't be bothered to learn how to use it properly.
It sounds to me as though you're getting an unhandled errror but insufficient information on what's producing it. You need the actual MDB to troubleshoot it, as the code isn't there to display in the MDE so there's no way to figure out what the actual source of the problem is. If your developer won't give you the MDB, then you need to check the contract under which the app was developed -- if you agreed to letting him control the source code, you're basically at his mercy and should fire whoever signed off on that. For what it's worth, when I deliver an MDE to a client, they also get the full MDB. They generally don't do anything with it, but should I no longer be available to do further development work, they've got the source code that they can give to whomever they want.
Last of all, I think it's very unlikely that even if you get your app working, a mere upsizing is going to offer much in terms of performance or stability. It is true that very often, 90% or more of an upsized app will work without alteration, but the other 10% can be very problematic. Often you need to move certain operations server-side to get the efficiency a server back end offers. This means your front end app needs to be re-architected to work better with your upsized back end. The degree to which this is true will differ from app to app, but it's very seldom that absolutely everything works without revision.
You did change Access database version?
It is possible that your mdb was linked with old version of Jet drivers and these drivers cannot connect to newer mdb version.
In a legacy project that I'm on, we have several processing that are preformed via DTS. DTS is not something I worked with a lot back in its hey day.... I was in college.
More specificity, these process are in ActiveX code blocks -- which is basically VBScript for database. It is really hard to debug.
Anyway, I'm wondering if any past or present experienced DTS professionals can offer tips on how to deal with debugging, troubleshooting or otherwise dealing with DTS package development.
This this question is marked as community wiki, I'm hoping to have general and targeted ideas and methods for all types of DTS package implementations.
I had a complex DTS package that imported some data, ran some batch scripts, made a CSV file and uploaded the resulting output via FTP. Sometimes the FTP process would fail.
I created a "DTS LOG" table and after each step I simply added a SQL insert task and wrote a time stamp and function name into the table. I made a view to show me any process that did not complete.
While this may not be as granular as you need, but at least you'll know where the problem is in the execution.
In the scripting portion, I have used the MsgBox to display "I got here" or "xfer worked" or whatever you want to indicate something happened which is not so obvious at run time.
You can also use conditional statements to branch off to an 'End' if you are testing a particular portion of the flow.
If you are stuck working with DTS, but are also running a SQL Server 2005 instance, you might see if you cant upgrade the DTS packages to DTSX (SQL Server Integration Services) and re-do them there. I know this isn't a 'trick' but you work in the VS2005 IDE, can write in .NET and also you can set break-points and will make life in 'DTS' world much easier.
There are also some articles here:
http://www.databasejournal.com/article.php/1503191
Scroll down and you will see the "SQL Server 2000 DTS" articles.