Jump to content

Search the Community

Showing results for tags 'firebird'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Delphi Questions and Answers
    • Algorithms, Data Structures and Class Design
    • VCL
    • FMX
    • RTL and Delphi Object Pascal
    • Databases
    • Network, Cloud and Web
    • Windows API
    • Cross-platform
    • Delphi IDE and APIs
    • General Help
    • Delphi Third-Party
  • C++Builder Questions and Answers
    • General Help
  • General Discussions
    • Embarcadero Lounge
    • Tips / Blogs / Tutorials / Videos
    • Job Opportunities / Coder for Hire
    • I made this
  • Software Development
    • Project Planning and -Management
    • Software Testing and Quality Assurance
  • Community
    • Community Management

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start




Found 4 results

  1. Firebird Embedded in a sandboxed MacOS App Friday, January 8, 2021 For those who might not be aware, Firebird on MacOS is now relocatable, in that you don't necessarily have to install it as a Framework, this also means that you can create an embedded version out of the current installer. And the firebird.conf file would then typically be amended for the following Providers = Engine12 ServerMode = Classic For the last few weeks Alex and I (along with a Firebird user) have been working on getting Firebird embedded to work properly in a sandboxed app that can then be deployed on the App Store... To do this we had to solve issues with temp files, the use of inter process communications by the Firebird lock manager and the location of the Firebird log file. Note: adding LSEnvironment to the plist file defining new locations for FIREBIRD_TEMP and FIREBIRD_LOCK does not work. <key>LSEnvironment</key> <dict> <key>ENV_VAR</key> <string>value</string> </dict> So the first issue to be addressed was the following macosx Wed Dec 2 15:33:57 2020 ConfigStorage: Cannot initialize the shared memory region Can not access lock files directory /tmp/firebird.tmp.YDzrhQ It seems thats sandboxed Apps cannot to write into /tmp at all, they have to use their own /tmp-folder. We can detect whether we are running in a sandboxed environment using the following calls to the Mac security subsystem task = SecTaskCreateFromSelf(nil), value = SecTaskCopyValueForEntitlement(task, "com.apple.security.app-sandbox" as CFString, nil), Now if we now know if we are sandboxed we can use NSTemporaryDirectory() for the location of the relevant Firebird temporary files. Having fixed that issue, it was time to move onto the lock manager. [FireDAC][Phys][FB]lock manager error.) macosx Thu Dec 17 17:37:00 2020 event_init() operating system directive semctl failed Operation not permitted According to the Apple sandbox guide restricting IPC (Inter Process Communication) is also part of MacOS sandbox implementation. After some serious head scratching we tried the following test #include <stdio.h> #include <pthread.h> #define ER(x) { int tmpState = (x); if (tmpState) { printf("Failed %s error %d\n", #x, tmpState); } } int main() { pthread_mutex_t mutex; pthread_mutexattr_t mutexattr; ER(pthread_mutexattr_init(&mutexattr)); ER(pthread_mutexattr_setpshared(&mutexattr, PTHREAD_PROCESS_SHARED)); ER(pthread_mutex_init(&mutex, &mutexattr)); ER(pthread_mutex_lock(&mutex)); ER(pthread_mutex_unlock(&mutex)); ER(pthread_mutex_destroy(&mutex)); c++ test.cpp -pthread In case of failure it will print error messages, on success we should get nothing. We got nothing. For many years Firebird worked with system V IPC on MacOS which is different to many other *nixes where mutexes and conditional variables in shared memory were used instead. The use of system V IPC was caused by a lack of for shared mutexes on MacOS when Firebird was originally ported to it. Currently (as was proved by test above) MacOS now supports such mutexes. Based on this it we decided to stop using system V IPC in Firebird and a perform a cleanup of the lock manager code as part of the effort to provide sandbox support. As a side effect Firebird should now run faster using shared mutexes. At the same time as we worked on the lock manager issue we also had an issue with the firebird log file, we were not allowed to write to its normal default location by the sandbox. Because we now know we are running in a sandbox we can relocate the placement of the log file within utils.cpp Supposedly using something like ~/Library/Application Support/Firebird/ should work case Firebird::IConfigManager::DIR_LOG: s = "~/Library/Application Support/Firebird/"; s += name; return s; Unfortunately it seems this workaround was removed relatively recently forcing us to resort to putting the log file within the App itself ~/LibraryContainers/Company.App/Data/Library/Application Support/Company/ Changing the location of the log file is relatively easy but although this allowed the App to run and resolved the issue, it was not an ideal solution since the location of the log file is now hard coded within Firebird and is App dependent and this would mean that every time somebody wanted an embedded Firebird for a sandboxed App they would have to change the path to the log file and recompile Firebird. The solution was to do away with the Firebird log file and use the OSLog framework instead, and use this to capture any messages from the database engine, so if you are running embedded Firebird in a sandboxed App you can access the Firebird log messages using the Console or a terminal command like the following log show --predicate 'eventMessage contains "macpro.home"' --start '2021-01-06 14:00:00' --end '2021-01-06 14:30:00' --info where macpro.home is the name of the computer. You don't need the start and end, but it does help reduce the number of messages. There is an added plus from using this. The OSLog framework is also supported on IOS 10+ and now that the App Store will accept dynamic libraries, this means that we should be able to compile an embedded version of Firebird for IOS that can also run sandboxed Apps. If anyone is interested in sponsoring this work please contact me. This work was sponsored by kiC Gesellschaft für Softwareentwicklung mbH. Posted by Paul Beach at 6:41 AM source: https://paulbeachsblog.blogspot.com/2021/01/firebird-embedded-in-sandboxed-macos-app.html
  2. Wij zijn op zoek naar een nieuwe aanwinst voor ons ontwikkel team in Oosterwolde. Syntri ontwikkelt een ERP systeem voor de maakindustrie, waarbij proces en workflow centraal staan. - Delphi 10.3 Rio VCL - iOS en Android ontwikkeling in Firemonkey - REST Api Vacature Software Ontwikkelaar
  3. Rafael Dipold

    TFDEventAlerter bug?

    I've created an MCVE that simulates a problem that eventually happens in our software, where software freezes when it tries to register an event when a previously registered event triggers within the same cycle. In an internal test, we found that this also occurs using the TIB_Events component. Would this be a Firebird or FireDAC bug? unit Unit1; interface uses Winapi.Windows, Winapi.Messages, System.Classes, System.SysUtils, Vcl.Controls, Vcl.Forms, Vcl.StdCtrls, FireDAC.Comp.Client, FireDAC.Comp.UI, FireDAC.Phys, FireDAC.Phys.FB, FireDAC.Phys.FBDef, FireDAC.Phys.IBBase, FireDAC.Stan.Async, FireDAC.Stan.Def, FireDAC.Stan.Intf, FireDAC.UI.Intf, FireDAC.VCLUI.Wait; type TForm1 = class(TForm) Button1: TButton; procedure FormCreate(Sender: TObject); procedure FormDestroy(Sender: TObject); procedure Button1Click(Sender: TObject); private FConn : TFDConnection; FEvents: TFDEventAlerter; procedure EventAlert(ASender: TFDCustomEventAlerter; const AEventName: String; const AArgument: Variant); public { Public declarations } end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.Button1Click(Sender: TObject); begin FConn.ExecSQL('EXECUTE BLOCK AS BEGIN POST_EVENT ''EVENT_1''; END'); FEvents.Names.Add('EVENT_2'); end; procedure TForm1.EventAlert(ASender: TFDCustomEventAlerter; const AEventName: String; const AArgument: Variant); begin Caption := AEventName + ' ' + DateTimeToStr(Now); end; procedure TForm1.FormCreate(Sender: TObject); begin FConn := TFDConnection.Create(nil); FConn.LoginPrompt := False; FConn.DriverName := 'FB'; FConn.Params.Values['DriverID'] := 'FB'; FConn.Params.Values['CharacterSet'] := 'ISO8859_1'; FConn.Params.Values['Server'] := ''; FConn.Params.Values['Database'] := 'c:\temp\whatever.fdb'; FConn.Params.Values['User_Name'] := 'SYSDBA'; FConn.Params.Values['Password'] := 'masterkey'; FEvents := TFDEventAlerter.Create(nil); FEvents.Connection := FConn; FEvents.Names.Add('EVENT_1'); FEvents.OnAlert := EventAlert; FEvents.Register; end; procedure TForm1.FormDestroy(Sender: TObject); begin FEvents.Free; FConn.Free; end; end.
  4. Hi, anybody had troubles performing a backup of a FB3 embedded database through the TIBBackup component? Firebird 3 uses fbclient.dll as client library also for embedded connections so it seems there's something wrong in the TIBBackup component when determining the client library to use (FireDAC.Phys.IBWrapper unit, TIBLib.GetLibraryInfo function. Given sLib var is always 'fbclient.dll' it misses it is a Firebird embedded connection). We tried to force fbclient.dll as vendor lib (giving a proper value to the DriverLink property of the TIBBackup instance, we also tried to set Embedded property of the driver link manually) but no way, it is always looking for fbembed.dll instead of the specified one (fbclient.dll). A quick and dirty workaround is to copy the DLL (fbclient) with the old name (fbembed) but I would like to avoid this, if possible. Any help would be appreciated. Maybe @Dmitry Arefiev may enlight us 😉 Thanks in advance