Starting databases

tamhas wrote:

Is that just the SQL connection failing because the server didn't start?
This is probably something simple, but I'm missing it tonight...

Because the broker didn't start, would be my guess; I assume the SQL is your secondary broker.  First I would check the broker ports, make sure no other processes are bound to them before you start the DBs.  And have you specified minport and maxport on your brokers, or are you using the defaults?  Are the DBs local to you, to do you go through a firewall to get to them?  Can you start them with a simple command-line proserve (with the same params) and connect to them with a Procedure Editor or sqlexp?  If so, that eliminates possible network conflicts like the above.

When you say "no evidence at all since 18 December", is that in the database log files, or your client logs?  Are your DBs actually running right now?  I'm not clear on that.

These are itty bitty databases with schema and essentially no data, entirely personal.  I have them marked for start and stop as I go in and out of Eclipse.  They are in the same directory as the workspace.

Very, very, very simple ... except the not working part.

In one error message I see "-S 50202" and in the other I see "Error establishing socket to host and port: localhost:50102.  Reason: Connection refused." Different port numbers so there is some inconsistency in configuration.

BTW: "Connection refused" is a socket library connect() error that normally means there is nobody listening for connections on the specified IP address and port. Looks like the server is listening on a different port.

I also have difficulties autostarting these small single-user DBs, from within Architect v 10.2B05.  It has to do with how they're setup in the project's properties - db connection .

To debug - when you start up Architect - in task manager you should see an _mprosrv.exe for each db that autostarts.  And yes I'm aware it's PDS now for v11.

If you use Process Explorer from sysinternals (via Microsoft now) you can see the Command Line details, which is very helpful for debugging this.

Mine lists "c:\dlc102b\bin\_mprosrv.exe -m 1 "c:/work/db/hltool" -N TCP -S 50004 -ipver IPV4

this connection "hltool" works fine but another one does not start.  This happens to me alot and when I'm offsite and needs these local db's I usually open a command prompt + start using proserve -S .

Then I can use it fine.  Annoying but functional.  I don't use my laptop often enough to really dig into it.

When I look at the Openedge - Database COnnections "browse" - (yours is likely worded differently with v11) - I can see my Auto-start Server is set to false and has no Server Parameters.

My working db has Auto-Start Server set to true and server parameters = -db c:\work\db\hltool.db -S 50004.  Also auto-stop server is set to false for the nonworking db.

So I modified the entry.  It's not the first page of the connection profile that needs editing, or the 2nd - sql connection properties - but the 3rd -

autostart db server [x] -

phsyical name is set ok -

add service/port = 50002 -

auto-shutdown db server [x]

when I finish - the browse has the settings the way I want them, which basically mimic the working db settings.

click ok to save - my project AVM restarts and now I get an "ok" for these dbs + can access all my db's again.

Your problem may be the same, or since it was working before - you just need to "view all" db connection in your project properties and make sure you have the proper db's toggled on for that project.

My problem was I was tweaking the sql connection properties and expecting that to make a difference.  Hopefully my process here will get you looking it the right spot to fix you up as well.

I started out with the 100 series and changed to the 200 series as one of my early attempts to get it working.  I didn't realize that I had to edit the SQL connection too since I was now reusing an existing connection ... makes sense, now that I think about it.  So, I have now changed the SQL connection to match and the SQL error has disappeared, but the databases are still not starting.  No lk file, no messages in the .lg, no connection to server.

I should have mentioned that I have another project in this same workspace which has its own DB and that one starts fine.

What are your database broker startup parameters?

Default only.  I only want them for the schema.

There's something I'm not following, clearly.  Perhaps a better question is, how does the 4GL/SQL configuration of the DB in your working project differ from the configuration of your non-working project DBs?

Other than being a different database in a different directory, they look identical to me.

databaseConnection.xml attached (sports not referenced yet)

One difference is that the three I am trying to use now were created with 11.0BETA, but the one that works was created recently with 11.0.

Aha!  Trying to start one manually gives me

OpenEdge Release 11.0 as of Fri Dec  2 19:01:49 EST 2011
11:14:08 BROKER     ** Database has the wrong version number. (db: 4266, pro: 42
69). (44)
11:14:08 BROKER     ** Database has the wrong version number. (db: 4266, pro: 42
69). (44)
11:14:08 BROKER     This broker will terminate when session ends. (5405)
11:14:08 BROKER     ** Database has the wrong version number. (db: 4266, pro: 42
69). (44)
11:14:08 BROKER     ** Database has the wrong version number. (db: 4266, pro: 42
69). (44)
11:14:08 BROKER     ** Database has the wrong version number. (db: 4266, pro: 42
69). (44)
11:14:08 BROKER     ** This process terminated with exit code 1. (8619)
proenv>

So, how do I do a conv11Beta11?

So, how do I do a conv11Beta11?

>

Dump & load, if you still have the beta bits. There's no built-in util that I'm aware of.

-- peter

So, there is a version change between beta and FCS?   Isn't that unusual?

And, what, exactly, would one use to do the dump .... I shouldn't need to, since I think I have the relevant stuff to build, but isn't there a catch 22 here?

Like I say, I think I can just recreate these because they are just schema holders and (I think) I have the .dfs.

But, it seems odd to me to have a version change of the DB between beta and FCS.

And, not to have this made highly visible on the beta forum so that people would know to take precautions before installing the released product.

>

So, there is a version change between beta and FCS?   Isn't that unusual?

 

That is not at all unusual. Furthermore, there have /never/ been converters

to convert from beta to a release. At least, not in the time I have been

here.

Then it seems odd not to have big warnings to dump beta databases prior to installing FCS.

Your'e right, there should have been warnings given. I don't recall seeing any.

Apologies.