Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Sriram

    Copy Encrypted InterBase Database to another machine

    @corneliusdavid, The RAD Server production license you get with your RAD Studio Enterprise can definitely be used in the scenario mentioned above. I do not see any violation of licensing/EULA.
  2. Sriram

    Copy Encrypted InterBase Database to another machine

    @corneliusdavid, thank you for posting your blog article in your response above. Now, I understand your issue a bit better. I am sorry you had a lot of difficulty using the product for your intended purpose. Here are a few things I want to clarify... You can use *any* number of InterBase instances on a single machine, as long as each of these instances are licensed and registered with a unique S/N Each InterBase instance has to be uniquely identified on your machine; this is typically the instance name you provide when you are installing either the normal InterBase product, or RAD Server (same installer as InterBase). The unique identification combination is the (1) instance name, and, (2) TCP/IP socket listening port for the InterBase server process. Each InterBase server instance will listen on their own unique socket port. Each install of InterBase (and RAD Server) comes with its own set of InterBase command-line tools, IBConsole, IBMgr, ibserver.exe etc. They are self-contained with their own user authentication database, admin.ib. The server instances do not share any database user accounts outside their own instance. On a single machine, you *can* have a mix of InterBase Developer Edition (downloaded from the product portal), InterBase Server Edition, RAD Server (production S/N), RAD Studio installed InterBase Developer IDE Edition (automatic install, optional in RAD installer) etc. And, you can install any number of InterBase versions as well, with any combination of Editions, provided you follow rule (2) above. If your InterBase Developer Edition or Server Edition has been used to Encrypt databases with their own SEP and Encryption keys, just remember that these databases should *not* be used with RAD Server (production) instance of InterBase; and, vice-versa, you should not try to access your RAD Server (production) databases from InterBase Developer Edition or Server Edition. The Developer Edition and Server Edition server instances do not know what the SEP should be to connect to your RAD Server (production) databases (as designed). By no means should a new install of InterBase should interfere with your current databases in use (by other instances), as long as you have not broken rule (2) above. From your application(s), my recommendation would be to use the TCP/IP localhost loopback going to that specific InterBase instance you want to connect. For e.g. your database URL would look like "localhost/<instance_name/portNumber>:<database_filepath>", as in "localhost/14064:C:/mypath/foo.ib", or, "localhost/gds_db:C:/mypath/foo.ib", or "localhost/ib2020:C:/mypath_ib2020/ib2020file.ib" etc. There is only one IBConsole.xml file used to store all configurations for the end-user of the system. So, I would always just launch the IBConsole from the most recent InterBase installation on your system, as this would have the most up-to-date feature set, and bug fixes. Whenever you install a new version of InterBase that supersedes other versions on your machine, just make a shortcut to the IBConsole from that install and launch that. In your IBConsole, when setting up a connection to a local/remote server, I would normally choose the localhost/loopback TCP/IP setup rather than the "Local Server" (IPC) connection. This helps me clearly identify which InterBase instance I am connecting to by specifying the instance name or the TCP port ID of the listening server. When you now use "Alias" (some more bugs for this are fixed in an upcoming release), the database alias is maintained in that InterBase server instance's admin.ib (user authentication database, stated above). For the InterBase Developer edition installed by RAD Studio, use the RAD Studio License Manager to manage it's licenses. For all other InterBase instances (including RAD Server production license), use the License Manager that is installed with InterBase (you can get it in the Windows shortcuts setup with your InterBase instance). Once you have done the above, please post any new observations. We can take it on from there, as this post is getting a bit long already. 🙂 Good luck! Best wishes, Sriram
  3. Sriram

    Questions about Interbase change views

    Bob, You can develop your application with a normal schema, and once completed, you can implement InterBase Change Views related subscription definitions, and update your application for those specific use cases. RAD Studio comes with a couple samples that go into further detail how to use InterBase Change Views with FireDAC components for fetching and merging changes to a local database, and vice versa. You may find this YouTube demo about InterBase Change Views and RAD Studio useful; Best wishes, Sriram
  4. Sriram

    Copy Encrypted InterBase Database to another machine

    David, The RAD Server Production license is not compatible with normal InterBase Production licenses. Even within RAD Server, there are 2 modes; development, and, production. The RAD Server database from a "development" environment cannot be just copied over to a production environment, and vice-versa. Since the "development" RAD Server license does not stamp the database file with any SEP (InterBase System Encryption Password), this database file can be used with normal InterBase Developer Edition. But, when you want to work with RAD Server Production deployment, you will want to rebuild your RAD Server database in "production" mode, so it uses a database file that is already stamped with a InterBase SEP value (not known to any user); you can save data in this as allowed by RAD Server schema. You cannot use a RAD Server Single/Multi-site production license to build your own InterBase encrypted databases where you need to know the SEP value. To use your own InterBase databases with SEP/Encryption, you will need to purchase a normal InterBase deployment license for Server Edition. I am sure you have already gone through the detailed demos/tutorials etc. about RAD Server. If not, here they are. Hope you find them useful. https://blogs.embarcadero.com/new-rad-server-ems-articles-resources-and-ebook/ https://cc.embarcadero.com/item/30879 In summary, if you want to create your own database schema with InterBase encryption, you will need to buy InterBase Server Edition license. If you want to use RAD Server license to store data as per RAD Server guidelines, you will not have access to any SEP value as that is hidden in RAD Server, to be available only for RAD Server database files (automatically). You can use a RAD Server database file with normal InterBase license, and vice-versa. Should you have any specific questions that we can help answer, please contact Embarcadero Support team at https://www.embarcadero.com/support. I am sure they can guide you further effectively. Also, please note that some of the documentation above do refer to InterBase 2017 from some years ago; current RAD Server uses the latest InterBase 2020 version, but the documentation still applies. Also, any reference to "purchase" a RAD Server deployment license is old (from many years ago); I understand RAD Studio Enterprise/Architect users get a deployment license for RAD Server included. Thanks. ~Sriram
  5. Sriram

    Interbase Metadata View User Privileges

    One cannot do this in InterBase. The database metadata is kept in system relations, and all the users have access to the system relations. So, they can see all metadata in the database. As the owner of the database, you can make the whole database metadata invisible to all users. Check $INTERBASE/examples/blindmeta.sql for this. There are also complimentary readmeta.sql and writemeta.sql to allow various access to the system metadata for all users. You either grant or revoke a (set of) privileges for users to the whole table (user defined or system tables); thus, you cannot grant a user a privilege for a subset of the records, OOTB. Now, you can modify blindmeta.sql to suit your needs, where you may want to make it all blind to a certain group of users, and give read/write privilege to others. Alternatively, a long winded way (I haven't tried this), would be to make system metadata blind to all users (using blindmeta.sql), and then write a custom stored procedure for users to see metadata for the tables/fields they have access to. You will need to grant "SELECT" privilege on the system relations for this stored procedure, and EXECUTE of this procedure to PUBLIC. Your stored procedure would internally validate the user against privileges they have on the "user tables" by looking up RDB$USER_PRIVILEGES, and only then execute the lookup to RDB$RELATIONS and RDB$RELATION_FIELDS/RDB$FIELDS which have the metadata for tables/fields. Your authentication logic is then centered inside the stored procedure, and achieves the control you want to have. Perhaps a lot more work than what you wanted, but possible I think.
  6. Sriram

    InterBase or Firebird?

    I would only add one more point to this. IBLite is available for free for deployment to Windows, Linux, macOS, iOS and Android from RAD Studio. So, for your small local database file, if the database is going to be less than 100MB size, IBLite would work well. It will be free for your current needs, and if you need to upscale to C/S solution or other features like encryption or changed data tracking, it allows you to take your database file directly to InterBase ToGo or Server for a cost. https://www.embarcadero.com/products/interbase/product-editions
  7. Roger, In your Project | Deployment section, please make sure you select the database file and have its "Remote Path" set to "assets\internal" for Android. The GetDocumentsPath() takes your database from this location. Also, the database file name is case sensitive; so make sure the database file name in your Project Deployment listing is the same as the one in your code where you are accessing it as thus... TPath.Combine(TPath.GetDocumentsPath, 'yourDatabase.ib'); I hope you have selected "InterBase ToGo" in the Featured Files selection to identify and deploy InterBase files to be deployed to Android, from within the IDE. See step (2) at http://docwiki.embarcadero.com/RADStudio/Sydney/en/Mobile_Tutorial:_Using_InterBase_ToGo_with_FireDAC_(iOS_and_Android)#Deploying_InterBase_ToGo_Required_Files_and_the_Database_File_to_Mobile