I got myself into a place where I need to port some functionality from a legacy Firebird database into MSSQL. The table schema and data was ok, all was enumerable and selectable for sysdba, however, the application layer is proving to be a pain.
The database has some 1000+ procedures and I would like to to move them over with some review rather than rebuilding the whole DAL. The problem is (you guessed) that they all appear to be encrypted somehow. When I ask to alter it to generate a script I get the ALTER script but the body of the procedure looks like a base64 string of some binary content. My first guess is encryption.
Is there some way to decrypt those bodies, like there is for MSSQL? Please note that Firebird database is running on its original box, in its original Firebird installation, nothing has been copied or moved, in case access to some keys is required.
When you create (or alter) a stored procedure in Firebird, Firebird will store the original body in column RDB$PROCEDURE_SOURCE of table RDB$PROCEDURES. This will not be encrypted. This body is not relevant for Firebird itself, as it will use the compiled form of the stored procedure (in column RDB$PROCEDURE_BLR); it is only stored to allow isql (and other tools) to generate the DDL script of the database.
Some software vendors don't like that people have access to their sourcecode, and so they will either null this RDB$PROCEDURE_SOURCE column or - as is likely the case with your database - encrypt the body in some way.
If this is an application that was developed in-house, you will need to find the original scripts used to build this database.
Otherwise there is no way to undo this without knowing exactly what the vendor (or developer) has done. Another possible solution would be to reverse engineer to stored procedure from the BLR (Binary Language Representation, the compiled form of the stored procedure), but I am not aware of tools that do this (and this might not result in very readable code).
Doing either of these might violate the license agreement, and maybe even local law. Your best bet would be to contact the vendor of this legacy application and ask (or pay) them for this source code.
The ISQL tool can print the BLR in 'readable' form, but as it is very low-level, I don't know how helpful that will be. For an example see this answer.
Since Firebird 3.0, database encryption is now possible ...so it has nothing to do with the Firebird installation, rather the database it self was already encrypted, I'm afraid you'll need the encryption keys to decrypt the data read these articles:
http://firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-security-encryption.html
http://tracker.firebirdsql.org/browse/CORE-657
Related
My application deserializes XML that is stored in a CLOB column in Oracle database to dynamically create forms. This approach allows relatively easy update deployment, but is too slow when a user connects through a VPN using e.g. 3G network.
I wonder is there a way to store those objects (forms) on the users's file system so that no parsing is needed?
I don't have any code to show but I hope this question is scoped narrowly enough to be acceptable.
My suggestion:
Make sure your form(s) is saved to the database in binary form, not as a text representation.
In your client app, request the CLOB column data from the DB and save it to a TMemoryStream. Then, you can instantiate the form by loading it from the TMemoryStream and it doesn't need to go near the file system on the client side. That way, no parsing of the Form data from the db is necessary.
The accepted answer to this q shows how to read a form from a memory stream - see the call to MemStream.ReadComponent et seq. Obviously, using tje method in that q, the CLOB data should have been created using the memorystream steps of its SaveComponentToFile.
I just wanted to do a quick sanity check with StackOverflow to confirm my suspicion. I'm creating an app and was tempted to use FMDB in Swift to store some data.I am treating this data as public in the sense that I assume it can be tampered with (and thus untrusted). This is because, after all, unlike a web app, this app runs on a user's device and thus they can access the .sql file and alter the database.
If I wanted to store information like if a user purchased something, unlocked certain weapons, or other data that I do not want to be altered in any way, I should not use a local database on the user's device.
Would you say this is correct and safe to proceed under this assumption? If I was looking to use the database to persist something important that took place, what would be a good approach? encryption with the key in the app, or maybe a hash or something?
If you want to secure your database, FMDB includes hooks for SQLCipher, which you have to obtain separately. See the various FMDB Encryption Methods that you can use once you have SQLCipher included in your project.
Im working on an azure database just adding a couple of Stored Procedures and just making sure the program I'm building with it in .NET is all aligned properly.
I'm not going to go into the Stored Procedure itself nor the Program I'm developing because I don't believe the problem is there, I have a Development program and database which is using the exact same code and they work fine, I'm using Microsoft's SQL Server Management Studio to handle everything on the servers side.
The only difference to the current setup is that I myself scripted a bunch of the Stored procedures and a single View of a table that I did not create....(I did not create the table, but I made a view for it which is a slightly different format)
The person creating most of these databases and table is one of the database administrators I guess (not Microsoft, but an employee of the company using their services), I on the other hand am a freelance programmer and I'm guessing I have somewhat limited access to the server (limited credentials).....although it's allowing me to do more or less anything I need to do like creating SP's etc.
My current (and only problem) is a single stored procedure that runs through without an error does not update the table (the table i did not create) the Stored Procedure just inserts a couple of records and then deletes a record from the same table.......
It deletes the record just fine but for some reason the INSERT doesn't insert anything.
Again, this works fine on another Development database and the programs are sending the exact same strings but this new database just doesn't want to play along.....
Could this be a permission problem I'm having between my stored procedure and the table I did not create?
I would love to dump this onto the admin guy (and already did but he dumped it back on me haha) so I just want to be sure I'm not wasting his time....... and give him something solid to go on.
Thanks for your help Paul S.
Currently I'm developing an iOS MMO game using cocos2d-x. The game uses many data tables (excel files) which are created by the designer. These tables contains such numbers as how much gold(crystal, etc..) will be needed for upgrading a barrack.
My question is, is that how to update that tables once if the tables have been modified on the server side?
My option: Use SQLite to store table on client side, once the tables has been modified on server side, the server will parse the tables (excel files) and send the data in JSON format.
then the client parse the JSON string and save that data to SQLite file.
Is there any better way? I find that some game stores CSV files on client side, how do they update those CSV files?
How you store the data (and in which format) is entirely up to you, although the framework does provide some helper classes (checkout ccUserDefault). The simplest way to check whethere data files on the client side are up to date is to checksum them (either apply a checksum to the data stored in the file or on the whole file itself). So to check for sync, the server side app applies a checksum to the data and so does the client (using the same algorithm, of course ;) ) and the numbers are compared; if they match, the data is in sync.
This is arguably more reliable if the server-side app generates the data files and sends them down, rather than relying on the client-side app to do it. But as long as the server knows how to generate data files using the same method that the client does, then the success of the client's file generation process can always be verified using this same checksum method.
I have a bit of problem here. I have created a lookupfield in my application server using Delphi XE2 DataSnap technology. On the client side, that field becomes TStringField. Now, the problem is that I loose the lookup functionality on the client side. To top that, I can't change the stringfield on the client side because it is read only (even if I manually turn off the read only property).
I don't want to lookup tables on the client side because I don't want all the data loaded on my client side just to support look up.
I can change the Key field value, but the stringfield lookup text doesnt change unless I apply updates and reload the data.
Users want to see the text change.
What should I do?
Seems you have to review your GUI functionality: lookup fields are really an client side feature. And it needs the lookup source - so to use it on client the lookup table must be loaded. DataSnap guys are very nice here, converting it to an TStringField when transmitting it to the client... I would simply ignore it.
So, if the lookup table is that big, you shouldn't using lookup fields but search UIs - or autocomplete comboboxes which you do queries against the DataSnap Server. Maybe you have to code it manually in the combobox case, I don't know (see if JVCL have something you can use to shortcut the path).
Alternatively, if the lookup table are seldom updated, you can aggresively cache it and have an updating mechanism to detect changes. So you can use the lookup fields the way they were created for.
Long time ago i faced that problem and i found a solution that is a bit complex to analyze here but i try to give some guidelines till i have the time to write a detailed blog post.
The idea consists of info (concerning lookup fields such as field properties, datasets, providers) packaged by the provider as optionalparams at the server side.
At client side a derived TClientDataset can unpack and process these info, create on the fly client datasets that retrieve needed lookup datasets and setup it's lookup fields accordingly.
The process is transparent due to the embedded functionality in the derived client dataset class and the only things to remember is to create that info in the provider's OnGetDatasetProperties event and turn false all provider flags in lookup fields.