Re: [fpc-pascal] Firebird embedded supported on Windows 64 by SEH patch
09.03.13, 15:49, Reinier Olislagers пишет: Sergei Gorelkin enabled Win64 SEH support in trunk r23732: * Make Win64 SEH support enabled by default. If necessary to disable, compiler should be cycled with OPT=-dDISABLE_WIN64_SEH. Mantis #24012. Does win32 SEH differs much from 64 bit version? Best regards, Paul Ishenin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Firebird embedded supported on Windows 64 by SEH patch
Am 09.03.2013 09:36 schrieb Paul Ishenin paul.ishe...@gmail.com: 09.03.13, 15:49, Reinier Olislagers пишет: Sergei Gorelkin enabled Win64 SEH support in trunk r23732: * Make Win64 SEH support enabled by default. If necessary to disable, compiler should be cycled with OPT=-dDISABLE_WIN64_SEH. Mantis #24012. Does win32 SEH differs much from 64 bit version? Yes, radically. It would be easier to implement arm-wince SEH first (which could also be used by a potential arm-winrt target btw.). In x86_64 and arm you have sections in your PE file that basically contain a pointer to the handler function and a memory range where the handler applies. On i386 you have a linked list of handlers on the stack that you (as in the compiler) need to manage manually. I386 SEH existed first in Windows and in the arm and x86_64 cases they learned from their problems. It would now be intresting to see how SEH on Dec Alpha, MIPS and PowerPC worked when the platforms where still supported by NT... Regards, Sven Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Sigsegv with refcounting interface
On 09 Mar 2013, at 02:37, Joao Morais wrote: On Fri, Mar 8, 2013 at 4:09 PM, Flávio Etrusco flavio.etru...@gmail.com wrote: procedure addintf(const aintf: IUnknown); (...) addintf(TInterfacedObject.Create); (...) It's a pity, but I don't know whether it's fixable (or if needs to be fixed) in the compiler. Works in Delphi 7 with FastMM4. [...] You are suggesting that this unlikely coincidente which causes a sigsegv should be the programmer's responsibility. No thanks, I much more prefer the Delphi compatibility =) It indeed only works by accident in your Delphi code. It is just as wrong in Delphi as it is in FPC. It depends on an implementation detail of the code generator's reference counting. It's like saying that a particular piece of code in which an uninitialized local variable happens to be always 0 in Delphi should have the same behaviour in FPC. We don't aim for compatibility as far as providing the same behaviour for code of which the result is undefined. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Firebird embedded supported on Windows 64 by SEH patch
Am 09.03.2013 08:49, schrieb Reinier Olislagers: Sergei Gorelkin enabled Win64 SEH support in trunk r23732: * Make Win64 SEH support enabled by default. If necessary to disable, compiler should be cycled with OPT=-dDISABLE_WIN64_SEH. Mantis #24012. Is it usefull to make DISABLE_WIN64_SEH a command line switch? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Connecting to Firebird using FPC/Lazarus over a LAN with user creation privilege
I don't know whether anybody can help me with this one, but I'm working on something where I need a program to be able to create login-capable database users on-the-fly. I was hoping to be able to use either PostgreSQL or Firebird as the backend, but while Postgres is working fine Firebird is proving to be sufficiently difficult that I might just drop it. Using isql-fb on Debian x86, I've created a database borg_ng with, among others, a user borg_um to which I've granted admin and rdb$admin rights. If I use isql-fb running either as root or as firebird with the rdb$admin role I can create a new user and verify it using gsec: # isql-fb -user borg_um -password password -role 'rdb$admin' Use CONNECT or CREATE DATABASE to specify a database SQL connect borg_ng; Database: borg_ng, User: borg_um, Role: RDB$ADMIN SQL create user test__4 password 'password'; .. GSEC di user nameuid gid admin full name .. TEST__4 0 0 Unfortunately I'm having a lot of difficulty doing this under program control, with the obvious difference being that FPC/Lazarus is connecting via a socket. Has anybody had anything like this working in the past? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Firebird embedded supported on Windows 64 by SEH patch
On 9-3-2013 13:51, Florian Klaempfl wrote: Am 09.03.2013 08:49, schrieb Reinier Olislagers: Sergei Gorelkin enabled Win64 SEH support in trunk r23732: * Make Win64 SEH support enabled by default. If necessary to disable, compiler should be cycled with OPT=-dDISABLE_WIN64_SEH. Mantis #24012. Is it usefull to make DISABLE_WIN64_SEH a command line switch? From my perspective: no, as it breaks using external dlls whose errors/exceptions incorrectly bubble up through to FPC. However, perhaps Sergei has another opinion... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Connecting to Firebird using FPC/Lazarus over a LAN with user creation privilege
Mark, You should be able to do this using the Firebird Services API. IBX exposes this API under the Firebird Admin tab and the TIBSecurityService class is what you are looking for. This has methods to DisplayUsers, which gets info on all users and puts it into an array property. Adduser, ModifyUser and DeleteUser - which should be self-evident. The original Borland documentation is not great but if you search on TIBSecurityService you should get most questions answered and its worth reading the Firebird Services API documentation to understand what is going on. Regards Tony Whyman MWA Software On 09/03/13 13:08, Mark Morgan Lloyd wrote: I don't know whether anybody can help me with this one, but I'm working on something where I need a program to be able to create login-capable database users on-the-fly. I was hoping to be able to use either PostgreSQL or Firebird as the backend, but while Postgres is working fine Firebird is proving to be sufficiently difficult that I might just drop it. Using isql-fb on Debian x86, I've created a database borg_ng with, among others, a user borg_um to which I've granted admin and rdb$admin rights. If I use isql-fb running either as root or as firebird with the rdb$admin role I can create a new user and verify it using gsec: # isql-fb -user borg_um -password password -role 'rdb$admin' Use CONNECT or CREATE DATABASE to specify a database SQL connect borg_ng; Database: borg_ng, User: borg_um, Role: RDB$ADMIN SQL create user test__4 password 'password'; .. GSEC di user nameuid gid admin full name .. TEST__4 0 0 Unfortunately I'm having a lot of difficulty doing this under program control, with the obvious difference being that FPC/Lazarus is connecting via a socket. Has anybody had anything like this working in the past? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Connecting to Firebird using FPC/Lazarus over a LAN with user creation privilege
On 03/09/2013 02:08 PM, Mark Morgan Lloyd wrote: I don't know whether anybody can help me with this one, but I'm working on something where I need a program to be able to create login-capable database users on-the-fly. I was hoping to be able to use either PostgreSQL or Firebird as the backend, but while Postgres is working fine Firebird is proving to be sufficiently difficult that I might just drop it. Using isql-fb on Debian x86, I've created a database borg_ng with, among others, a user borg_um to which I've granted admin and rdb$admin rights. If I use isql-fb running either as root or as firebird with the rdb$admin role I can create a new user and verify it using gsec: # isql-fb -user borg_um -password password -role 'rdb$admin' Use CONNECT or CREATE DATABASE to specify a database SQL connect borg_ng; Database: borg_ng, User: borg_um, Role: RDB$ADMIN SQL create user test__4 password 'password'; .. GSEC di user nameuid gid admin full name .. TEST__4 0 0 Unfortunately I'm having a lot of difficulty doing this under program control, with the obvious difference being that FPC/Lazarus is connecting via a socket. Has anybody had anything like this working in the past? Have you tried the fbadmin unit that comes with 2.6.2? It implements some of the interbase service routines such as user management and backup/restore. There has a convenient AddUser method. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Connecting to Firebird using FPC/Lazarus over a LAN with user creation privilege
On 03/09/2013 03:03 PM, Tony Whyman wrote: Mark, You should be able to do this using the Firebird Services API. IBX exposes this API under the Firebird Admin tab and the TIBSecurityService class is what you are looking for. This has methods to DisplayUsers, which gets info on all users and puts it into an array property. Adduser, ModifyUser and DeleteUser - which should be self-evident. The original Borland documentation is not great but if you search on TIBSecurityService you should get most questions answered and its worth reading the Firebird Services API documentation to understand what is going on. Regards Tony Whyman MWA Software That is exactly what the FBAdmin unit is doing using the Services API. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Connecting to Firebird using FPC/Lazarus over a LAN with user creation privilege
Ludo Brands wrote: On 03/09/2013 02:08 PM, Mark Morgan Lloyd wrote: I don't know whether anybody can help me with this one, but I'm working on something where I need a program to be able to create login-capable database users on-the-fly. I was hoping to be able to use either PostgreSQL or Firebird as the backend, but while Postgres is working fine Firebird is proving to be sufficiently difficult that I might just drop it. .. Have you tried the fbadmin unit that comes with 2.6.2? It implements some of the interbase service routines such as user management and backup/restore. There has a convenient AddUser method. Thanks Ludo and Tony, I'll take a look at that a bit later in the day but I'm sure I'll have more questions. What I'm trying to do is set up a tree of database servers and apps, and was hoping to allow cooperating admins to use Firebird at the leaf nodes on account of its perceived ease of configuration etc. Having said that, if I have to start moving outside standard SQL to do things like user creation, i.e. maintain both SQL-based commands for PostgreSQL and API sequences for Firebird, much of the perceived advantage disappears. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Connecting to Firebird using FPC/Lazarus over a LAN with user creation privilege
Mark, I did something like this a few years ago and the Services API is your friend - but it is not standard SQL... Regards Tony Whyman MWA On 09/03/13 14:38, Mark Morgan Lloyd wrote: Thanks Ludo and Tony, I'll take a look at that a bit later in the day but I'm sure I'll have more questions. What I'm trying to do is set up a tree of database servers and apps, and was hoping to allow cooperating admins to use Firebird at the leaf nodes on account of its perceived ease of configuration etc. Having said that, if I have to start moving outside standard SQL to do things like user creation, i.e. maintain both SQL-based commands for PostgreSQL and API sequences for Firebird, much of the perceived advantage disappears. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Firebird embedded supported on Windows 64 by SEH patch
In our previous episode, Reinier Olislagers said: Is it usefull to make DISABLE_WIN64_SEH a command line switch? From my perspective: no, as it breaks using external dlls whose errors/exceptions incorrectly bubble up through to FPC. However, perhaps Sergei has another opinion... Probably he is only careful. Which is only wise. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Connecting to Firebird using FPC/Lazarus over a LAN with user creation privilege
Tony Whyman wrote: Mark, I did something like this a few years ago and the Services API is your friend - but it is not standard SQL... [Nod] I suspect that the key is the way that Firebird documents various activities as differing subsets of SQL, i.e. defining a table is one subset, accessing it is another, managing users a third and so on. I could have been naive in assuming that isql's CREATE USER was submitted as such, rather than being translated to API call(s) inside the program. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Connecting to Firebird using FPC/Lazarus over a LAN with user creation privilege
On 9-3-2013 17:31, Mark Morgan Lloyd wrote: Tony Whyman wrote: Mark, I did something like this a few years ago and the Services API is your friend - but it is not standard SQL... [Nod] I suspect that the key is the way that Firebird documents various activities as differing subsets of SQL, i.e. defining a table is one subset, accessing it is another, managing users a third and so on. I could have been naive in assuming that isql's CREATE USER was submitted as such, rather than being translated to API call(s) inside the program. Don't know exactly what you mean by differing subsets; AFAIU they're all regular SQL as far as Firebird is concerned. They should work in e.g. Flamerobin just as they do in isql. Management tasks that used to only be exposed by the services API are now also being offered through SQL (user management, grant management...) You do need to pay attention you're not using some prehistory FB version - don't know when exactly CREATE USER was introduced, probably in 2.0 or 2.1 or something... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Connecting to Firebird using FPC/Lazarus over a LAN with user creation privilege
Reinier Olislagers wrote: On 9-3-2013 17:31, Mark Morgan Lloyd wrote: [Nod] I suspect that the key is the way that Firebird documents various activities as differing subsets of SQL, i.e. defining a table is one subset, accessing it is another, managing users a third and so on. I could have been naive in assuming that isql's CREATE USER was submitted as such, rather than being translated to API call(s) inside the program. Don't know exactly what you mean by differing subsets; AFAIU they're all regular SQL as far as Firebird is concerned. They should work in e.g. Flamerobin just as they do in isql. Management tasks that used to only be exposed by the services API are now also being offered through SQL (user management, grant management...) You do need to pay attention you're not using some prehistory FB version - don't know when exactly CREATE USER was introduced, probably in 2.0 or 2.1 or something... It identifies itself as 2.5, and by that I explicitly mean that I'm querying it rather than trusting any claims by the Debian package maintainer, and according to the documentation that's the version at which rdb$admin system role was added. I suspect that I'm supposed to be doing something like granting rdb$admin to the user concerned in the security database, but so far I can't work out how. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Set size limit
Hi, I am trying to create a Set Type... TMyEnum = (me1, me2, me3); // more than 500 elements TMySet = set of TMyEnum; ...but I get the following error: Error: illegal type declaration of set elements [1] The problem seems to be that TMyEnum has more than 256 elements. Can I specify such Set with some compiler option ? My fpc is pre 2.6, any change on new versions concerning Sets limits? Thanks. [1] A more specific message would help too. :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Set size limit
On 09 Mar 2013, at 21:52, Daniel Gaspary wrote: The problem seems to be that TMyEnum has more than 256 elements. Can I specify such Set with some compiler option ? No. My fpc is pre 2.6, any change on new versions concerning Sets limits? No. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What's a unit?
Hi, On 2013/02/19, at 22:53, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Mark Morgan Lloyd said: Does a unit- rather than something it contains- have any sort of representation which is recognisably distinct from an object? Maybe. But what it certain doesn't have is a runtime instance. unit is mostly a compiletime concept, and the Delphi exceptions to that (mostly due to package system) are not implemented. I've never though of it that way, but certainly that's true in the sense that if you want multiple objects, you can instantiate them at run time. With a unit, you only get one. In a sense, then, a unit is like a class with only class methods. In fact, even without having used those words - when I design a program for something where I know I will only need to track the state of a single item, I will often use units. As soon as it's likely I will need to track the state of multiple items (particularly an unknown number of items), I have to think about using arrays i the unit, or just converting to objects. I've got a situation where if a library (.dll or .so) is opened under program control it is represented by an object, with entry points expressed as methods. Alternatively, if it's statically linked then it's represented by a unit, with entry points represented by procedures and functions. That allows me to write things like Sadly this kind of thing has been one of the drawbacks of existing pascal implementations. For example, you have program A which uses unit B. You want to make B dynamic, so you convert it into a library (.so or .dll). But you still want to use it in your program. Back when I did this, at least, that required writing another shim unit which pulled in everything in the library. It's understandable that you need the shim if the original program was written in C, etc., but a bit silly in the case where both were pascal. Making full use of dynamic linking has been a pain in general. (I prefer static linking most of the time, but there are advantages and disadvantages to both). Your case isn't a lot different - but a unit can't do everything an object can anyway (as discussed above). Probably the easiest thing for you to do is have the unit and the library both include a file with the object code. That's not pretty, but it's better than double maintenance I suppose. No, that does not exist to my best knowledge. Delphi might have ways for packages, but that is also shaky (and target dependent) at best. The only way is to define a record with procedure variables for the static case manually I guess. Thank you, Noah Silva ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] differences between .pp and .pas files
Hi, I also always use .pas, but the idea of using .pp for sources only intended to compile in FPK and .pas for more portable source code is interesting. The only problem is there is no free Delphi for me to test with anymore, right? Since FreePascal works on nearly every platform, I don't worry too much about Delphi anymore. (and GNU Pascal ha ha ha...). Interestingly enough, I used to use Pure Pascal, where .pp would have made sense (but I used .pas there too...) Thank you, Noah Silva On 2013/02/25, at 20:00, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: On 2013-02-25 10:51, Sven Barth wrote: That's indeed a valid argument pro .pp And a large argument against .pp extensions is that NO editor out there (except for FP Text IDE and Lazarus) knows about .pp, so pascal syntax highlighting never works. You have to always manually force the pascal syntax highlighting, or if the editor allows, manually add the .pp extension for the Pascal highlighting. Out of principal, I always use .pas ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Exe file names (was:differences between .pp and .pas files)
Joao, I think you had better be careful what you say. Someone will rename their entire /usr/bin directory and wonder why the system stops working! You can rename executables you create, but don't change the names of standard ones! Anyway you can tell what programs unix will *try* to run based on the execution flag (ls -la). As an aside, on Max OS X, you will see: 1. Command line programs with naked names like runme 2. GUI programs with names like runme.app. (X11 programs have no .app extension usually). Atari's GEM system also used .app, but it was just an extension, like in DOS. Mac OS X has Bundles, and an Application is a special type of bundle. A bundle is a kind of hybrid between a directory and a single file. In current OS X versions, it is basically a directory that is treated as a single file by the GUI, and has some special bits set on the fielsystem - but you can enter it using the command-line, or using some comment like browse bundle contents in the GUI if you know what you are doing. Inside the bundle, then, you will find the naked executable file somewhere with no extension. So if you are making command-line apps, then it's just like any other BSD. If you are making native GUI apps, then there is some special sauce. Luckily Lazarus handles this for you... Thank you, Noah Silva On 2013/02/26, at 8:51, Joao Morais jcmorai...@gmail.com wrote: On Mon, Feb 25, 2013 at 8:03 PM, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: I quite like this idea. I have always hated *nix systems that don't use extensions for executables. Rather hard to quickly search for executables in a directory hierarchy, where with a file extension it is much easier. find -type f -executable Btw .bat is also executable. And nothing prevents you from naming your nix executables with the .exe extension. Joao Morais ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
Hi, On 2013/02/28, at 9:16, Simon Kissel sc...@untergrund.net wrote: I still believe FPC should leave the delphi compatible idea, or clearly state that it means compatible with Delphi 7 for legacy purposes and nothing newer. Then innovate the rest of the language on its own in a Pascal-like manner. This is a terrible idea. The business advantage of Object Pascal has always been the component market, as it reduces development costs and time to market. Language compatibility between FPC and Delphi results in more components being available on both sides. I tend to agree. More specifically, I personally like the idea os having Pascal be its own run-time (or, ahem, compile time) environment, somewhat like Java, more than a bare-bones language like C. We can have compatibility of built-in functions and syntax, while having a native compile system - which gives us some advantages over both C and Java. The Object Pascal language is too fragmented already, and depending on your choice of the Delphi/FPC/Oxygene/whatever flavour, you are Oxygene may be cool and all, but I think it's not really pascal anymore. Delphi has most of the time used the term ObjectPascal hidden in their documentation, and it is clear that it is an evolution of TurboPascal. Oxygene (and Delphi.net) seem to be much more clean breaks in the pascal style to me. locked out of a hell lot of available source code, documentation, knowledge and components. Right now pretty much every commercial component we have to patch inhouse to be compatibile to FPC. Yes, on the GUI level, I wish things would be more compatible, not less. I don't like having to convert forms, etc., much less code. (On a side note: It's one of the goals of CrossFPC to make it easier for Delphi users and component vendors to also use/support the FPC compiler.) Sticking to D7 compatibility has been OK for now as this is what the masses and component vendors mostly are doing, too, as they still have to support D7 users. I can only trust that this is true. I used to be a Delphi programmer at work, but now it's only for small projects. (When I do major programming at all, it's in ABAP or sometimes Java). We ourselves have to stick with D7 language level because we still need CrossKylix for our Linux builds because the FPC compiled code is prohibitively slower than Kylix' one. Heh, I noticed this when porting the FPC run-time-library to VirtualPascal in like... 2001 or so. It worked, but it was much much slower. This is something that would be great to fix, but on the other hand, doing it in Pascal Source means there are some limitations. Still, it would be a great summer of code project. FPCs goal to move towards D2009+ language compatibility is a right goal - but of course that does not mean that everything needs to be copied, but when things on the Delphi side are designed in an OK manner, are actively used in the field, and FPC wished to do the same, aiming for compatibility is a good thing. Should FPCs share of the object Pascal ecosystem one day should be *significantly* larger than Delphi's, sooner or later Delphi then will try to pick up FPC's innovations instead. I wonder if it isn't already. Simply not for large businesses. In the long run, new object pascal language features optimally should be discussed by those active in the field BEFORE they get implemented. Sadly right now Embarcadero still are far too arrogant and close-minded to understand that FPC actually benefits the ecosystem they sell products in. Well I don't know if I would use the fighting words, since I haven't met them personally. They probably have mixed feelings about FPC. On the one hand, we are on their team, and FPC allows them to support iOS, etc. (I am sure they see the advantage in that!). On the other hand, we are to some extent a competitor as well. Delphi has certainly become less popular since v6, and I think FPC has probably become more popular. Still, I think that if FPC wants to do something that Embarcadero has no interest in, then we can do it our own way. If they implement a feature in a certain way, we should try to mimic it as closely as possible in order to have the highest code compatibility. The worse case I have seen right now is where we implement something, and then they come along and implement it differently (ahem.. generics). They should realize that a lot of people use both products, and all kinds of forums to find answers on. Then they look up How to use generics in Pascal, we want there to be one single correct answer. Not like Well, if you're using Delphi it will be this way, and if you're using FPC it will be this way, because most of the time, specific products names may not be mentioned. All this being said: I know that FPC is not after business goals. I think FPC is after having as many users as possible and developing a high quality system. Clearly,
[fpc-pascal] Re: Connecting to Firebird using FPC/Lazarus over a LAN with user creation privilege
On 9-3-2013 19:56, Mark Morgan Lloyd wrote: Reinier Olislagers wrote: On 9-3-2013 17:31, Mark Morgan Lloyd wrote: It identifies itself as 2.5, and by that I explicitly mean that I'm querying it rather than trusting any claims by the Debian package maintainer, and according to the documentation that's the version at which rdb$admin system role was added. I suspect that I'm supposed to be doing something like granting rdb$admin to the user concerned in the security database, but so far I can't work out how. Glad you trust the Debian maintainers then ;) Well... Background: Create user via SQL: http://www.firebirdsql.org/refdocs/langrefupd25-security-sql-user-mgmt.html CREATE USER mark PASSWORD '8charmax' -- if you want to let that user add other users, add GRANT ADMIN ROLE GRANT ADMIN ROLE gives the new user the RDB$ADMIN role in the security database. This allows him to manage user accounts, but doesn't give him any special privileges in regular databases. Yes granting rdb$admin for full control seems like a good idea: http://www.firebirdsql.org/file/documentation/reference_manuals/reference_material/html/langrefupd25-security-rdbadmin.html Connect to the target db GRANT RDB$ADMIN TO mark (execute as e.g. SYSDBA) Don't forget this: To make use of his RDB$ADMIN privileges, the grantee simply specifies the role when connecting to the database. i.e. TIBConnection.Role:='RDB$ADMIN' ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
