| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Comments:
<0> var ok: Boolean; begin ok := false; while not ok do begin { input } if ... then begin writeln('ACess allowed'); ok := true; end else begin writeln('Invalid username/p***word'); end; end;
<1> ooo
<1> anyone use IBExpert?
<1> I'm so confused with Firebird :( So much info on the net, so many administration tools...super-server embedded server cl***ic server /me screams?
<0> well...
<0> You want the super server
<0> or the embedded one if you want it as an embedded db with your app
<0> admin utility: I use the one from firebirdsql.org
<1> What confuses me is how I am to write my program... I have a few design dilemas
<0> Flamerobin
<1> I looked at that...
<1> there're so many fancy ones out there though
<1> You mind if I ask you in private?
<0> I think it's better to ask here
<2> ehhh
<0> so the rest can answer too
<2> if you have multiple cpu's you'll probably want cl***ic
<0> ah see
<0> there
<2> otehrwise use superserver (and embedded for embedded of course)
<0> I'm already corrected.
<1> It's just db going to be on server at work... I also will need to be able to install it without fuss as the project might be used by other clients, so do I need them to install the db using the firebird setup :/
<1> I need some food :()
<0> mith: they still don't do proper multicpu support ?
<0> with the super serve
<1> ooo guys I got 16mbit line now... it's kind of sick.
<1> downloads at 2mb a second
<0> TByte: also, you really should read the FAQ
<2> ki9a: no ... probably in 3.0 when the vulcan merge is complete
<0> http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_ss_vs_cl***ic
<0> MithWork: shame.
<1> gonna cook some eggs, then read that, then ask questions :P
<2> TByte: installing firebird is very very very easy
<2> just get the .zip and then all you have to do to install is run a .bat file
<2> or run the commands in the .bat in your own program
<0> or if you use the setup
<0> it's click and go ;)
<2> yeah
<2> but using the .zip files you can very easily integrate it into your own setup
<0> right
<0> they have an innosetup script somewhere too
<0> hey daedo
<3> hi
<1> damn im consuming too many eggs
<1> 3 a day :/
<1> So I have to write this client-server marketing tool for work. Server-side has a database of contacts, html templates and web-server. Client should be able to retrieve the contacts on server, upload html templates, and schedule monthly newsletters. There're will be only half a dozen clients to the server. So should I use cl***ic or super-server architecture?
<2> depends
<2> how many cpu's ?
<1> 1...
<2> superserver then
<1> not powerful pc really.
<2> doesn't need to be, firebird has a small footprint
<2> we run our data warehouse on .. eh ... A PIII 500 or something
<1> Thing is the db will not be used aggressively, most work will be done on client side, designing the newsletters etc... so there's no need for fancy stuff
<2> yeah, superserver is fine
<1> that implies everything will be via tcp/ip?
<2> don't let the name fool you, teh reason it's calle dsuper is because it uses one instance for all connections
<1> (which is fine with me, I like that)
<2> it doesn't imply anything
<1> o
<2> you want to use TCP/IP, either will work
<2> you cant to use named pipes, same story
<2> s/cant/want/
<2> default install of either cl***ic or superserver listens on port 3050 TCP/IP
<1> ...the client, should it connect directly to the db? or should I write an intermediate server of my own to relay the queries?
<2> up to you
<4> I prefer superserver just because its a more traditional DB architechure.
<2> easiest is to let it connect directly to teh database of course
<1> well...client needs the db, but it also needs to be able to schedule stuff on the server, so i donno how to design this
<2> just set the database name in whatever component you're using to serveraddress:databasefile-or-alias
<1> ok
<2> e.g.: my.database.com:C:\data\database.fdb
<2> or you can put in a middle tier
<0> super sounds more stable
<0> locing wise and all
<0> locking
<1> yeah, what if I want to write a program on the server to communicate with the db... the webserver will need to be able to write to the db too... will it communicate with the db the same way the clients would?
<0> you haven't thought through the design that much ?
<2> yes
<2> or you can use named pipes on the server and tcp/ip on the clients
<1> I have :
<0> MithWork: tcp/ip and named pipes don't differ much
<2> this is not database dependant btw, the same questions woudl arrise with any other database
<1> yes, I figured
<0> it might even be that sockets are faster
<2> ki9a: yah I know, but I don't really know what else there is ... I think there's a localhost protocol too :)
<0> yeah there is
<0> it uses messages IIRC
<2> yeah but I'm not sure that one works with superserver
<0> cl***ic you mean ?
<0> I would have expected it would work with super better
<2> no I think it worked with cl***ic but they didn't implement it for super .. or something
<2> not sure it's the same one tho....
<0> I do recall they just reimplemented it
<1> it wouldn't be too much of a resource waste if I was to connect clients to the db , as well as my own server on the server
<0> for v2
<1> ki9a: i thought of a design for a while, but mainly on the finer details, these questions probably show how unfamiliar I am with how dbs work remotely...
<0> how will your clients connect ?
<0> directly to the dbserver?
<1> yes, I think now I'll do that
<0> so everybody talks to the dbserver directly?
<1> yep :/
<0> MithWork: the new Ipserver (local) protocol uses shared memory (new in v2)
<0> and now _also_ works with the cl***ic server
<0> and with non-interactive services
<2> okay
<0> and terminal servers
<1> that's why my boss insisted I write it all in php, then iut's all done through webserver... but that's why I was asking, should I write an middle server
<0> NetBEUI isn't supported anymore.
<0> well if the frontend is going to be php in a protected zone
<2> TByte: that depends entirely on what the middle server would do
<1> no, I dumped php idea, I will spend too much time
<0> ooh
<0> well I would never connect directly to firebird from remote client
<0> then agian
<1> but he wanted it originally in php, because that's how a similar site he saw worked.
<2> ki9a: why not ?
<0> I sell middle tier software
<0> :)
<2> heheh
<0> MithWork: security
<2> nothing wrong to talking to the db server directly if you know what you're doing
<1> middle server will only check on the database if it has any fresh jobs to do
<1> if it does, it'll start the jobs
<0> hrmm
<1> ki9a: yeah I had a browse on your site
<0> no security layer?
<0> everybody uses sysdba/masterkey? :P
<2> ki9a: well teh only security concern is somebody trying to freeze the server by sending heavy queries
<0> right
<0> you can lock down firebird pretty well
<2> yeh
<0> though I never found a way to adjust the queries on a per-field level
<2> you can do a lot with stored procedures :)
<0> MithWork: with DA I can say, oh that user, he can get/update all records as long as field xyz is abc
<1> how hard it is to write a middle-tier, so it's transparent to the client?
<2> that said, if my current application goes live to clients there will be a middle layer
<2> and clients will send an XML definition of the query instead of straight SQL
<0> TByte: the client wouldn't use the firebird/interbase components
<0> TByte: instead it would use whatever middleware components you'd use
<1> damn
<0> and use that to request/send back data
<1> like yours :P?
<0> the idea of middle ware is pretty much the same
<0> I'd like to think our implementation is a bit better
<0> ;)
<2> and earns him more :P
<1> so I can write it myself, just add whatever stuff I need to use of the database to the middle-tier
<0> MithWork: that too
<0> yes.
Return to
#delphi
or
Go to some related
logs:
nicole nairan
#computers
Dubai Gigayacht
#netbsd
#sql
#goal
#beginner
#red
#freebsd
Linux Portiable
|
|