At 05:35 AM 8/11/2007, you wrote:

>After toying with this all day, it would appear my problems are many. Creating a gds32.dll (usning instclient.exe) certainly helped with the connection problems. But when I looked at my data (logged in as sysdba) I had garbage characters in a number of fields, one of them a memo field.

Check to make sure you are using the right character set in your connection and that you "memo field" is actually a sub_type 1 blob.

>Tell me, is it possible to use a security2.fdb that resides on my development PC, when talking to a DB that resides on a different server PC?

No. If you are talking to a DB that resides on a different host, then you are doing so as a client to that remote server. The security database, message file and all the other stuff at that server are used.

>EMS SQL Manager gives me an option to tell it where the security db lives. But it seems like a HUGE problem if I can use the seucirty DB on a different PC to access a DB on another PC.

You can't. Probably the purpose of collecting that parameter was for some wrapper utility the tool has for running GSEC remotely.

>I've been tinkering with FB since 1.5 (I am running on Win2K btw) and now at 2.0.3. Between 1.5 and 2.0 I did a backup/restore to update the ODS. Do I need to run such a procedure between all revs? ie 2.0 to 2.0.1? I wouldn't have thought so.

No. But do check the dialect of your database. Backup/restore doesn't turn a D1 database into a D3 one.

>finally, I am running the latest rev of EMS SQL Manager 2005 - version 4.4.0.5. It claims to support both IB and FB. Is it possible that changes have been made in the FB internals making it no-longer compatible?

Of course it is possible. For one thing, the security has changed in v.2; but also many things have been corrected and tightened. It's to be expected that applications that took advantage of doubtful syntaxes that are no longer allowed would have to be fixed up. The issue isn't whether your application supports both FB and IB, it's whether it supports the current releases of those products.

>I am now more concerned about the data corruption then my privilege issue. so tomorrow I'll give it a fresh start (all dummy data at this time) and see what happens. But my first impression is that FB is perhaps not so stable. After all, I didn't exactly hit FB over the head with a sledge hammer. I was trying to follow best practice (ie the backup/restore business) and I still managed to mangle the data.

Your environment is the area where you seem to have instability. If there is not a more recent release of that application available (and I don't know - you could ask on firebird-tools and/or search its archive) then get hold of another admin tool; or use isql.

>I am too new at FB to really know where to point the finger. I know all the "gotchas" for Paradox tables. I would imagine this will be Lesson #1 when I sort it out.

Yeah, there's nothing so valuable as learning from your mistakes. But studying the Quick Start Guide and the release notes (in the doc directory) would be useful as well.

>ps- have you updated your book to fully cover 2.0? The version I have covers up to 1.5 and talks about 2.0 but clearly was not released when my copy went to press.

Correct, it was published when 1.5 was new. There is a Fb 2 supplement available for purchase from the IBPhoenix website.

>bloody great book! best and only reference book needed, once it covers 2.0 in full.

The next edition will be for Fb 3. In the meantime, there will updates for the supplement at significant milestones.

./heLen