SQLBase 12.0.0 10579

[BrianBulaw]

I installed SQLBase 12 on a Windows 2012R2, fully patched VM under Hyper-V. The service was not installed. I run the .exe starting it four times with different sql.ini's. The database and programs run fine until I File, Exit from the console, and then the database crashes. This is going to cause problems when we automatically shut the databases down to do full copy backups.

Regards,
Brian Bulaw

[Mike Vandine]

Hi Brian,

So you have SQLBase 12.0 running in 4 instances of the machine? Do they all have their own versions of the SQLBase Console, i.e. do they have their own consoleport definition in the sql.ini files? And their own listenport as well?

Is there a fail.sql file for the crash? You say the database crashes. Do you actually mean the server crashes? If you have 4 versions of the server running (different sql.ini files), do they *all* crash or just one?

Do all of them behave this way, i.e. is there any particular instance that always crashes and others that don't?

Are you connecting using tcpip or npipe or apipe?

Can I see a couple of the sql.ini files?

[BrianBulaw]

Hi Mike,

All instances have their own console.
There are no fail.sql files on the server.
If I open a console and immediately shut it down, the console exits without errors. If I use SqlTalk to select a table, then the individual console will crash on exit. The other consoles continue to run, and the crashed console can be restarted without problems.

Thanks,
Brian Bulaw (UTC-5)
Cell: 011-214-729-6538
Skype: BrianBulaw

[Mike Vandine]

Hi Brian,

Thanks for the files.

Another question. Do you have the dump turned on for a crash? Run the crashreporter.exe and make sure it's turned on. Untick the 'Delete dump file' and select 'Medium' for the minidump. Once that crashes, send me the dumpfile directly.

A couple of suggestions:

cache=1000000

I would reduce that to 256000 (or 512000). Just because you *can* have a cache that high doesn't mean you *should*.

I would turn off the npipe and try TCP/IP. So:

NamedPipes=No <-- You have this defined in two separate places. Delete one of them.
transports=tcp,npipe

Set the readonly=0. I know you have a comment that this gives an error in SQLTalk. Before you set this, go into SQLTalk, click on Options/Settings, then select Release Lock as the isolation level, tick the 'Save settings on exit', then exit SQLTalk. You should now be able to set the readonly=0 and have SQLTalk start up correctly.

Let me know how this goes.

Best regards,

Mike

[Mike Vandine]

Hi Brian,

I cannot reproduce this. Can you please try the tcp/ip change and see if that makes a difference?

Thanks!