Console app

[Jim Patek]

Does anyone have a working console app using pgSQL4RB that you could
share the code for. I can get the GUI stuff to work fine, but the
console part seems to elude me. I know that I am probably overlooking
something simple, but I seem to be completely shorted to ground here.

Thanks
Jim Patek
***@patekworld.com

[Aliacta Support]

Post by Jim Patek
Does anyone have a working console app using pgSQL4RB that you could
share the code for. I can get the GUI stuff to work fine, but the
console part seems to elude me. I know that I am probably overlooking
something simple, but I seem to be completely shorted to ground here.

Hi Jim,

Here's the base principle:

Create two subclasses, one for the socket and one for the cache.

Here's the App.Run event:

Function Run(args() as String) As Integer

Dim TheSocket as MYSUBCLASSpgSQLcoreSocket

TheSocket = new MYSUBCLASSpgSQLcoreSocket

TheSocket.DatabaseName = "mydatabase"
TheSocket.UserName = "postgres"
TheSocket.Password = ""
TheSocket.Port = 5432
TheSocket.Address = "localhost"

TheSocket.Connect

While TheSocket.IsConnected
App.DoEvents
Wend

Return "anything"

End Function


Here's your socket-subclass' Connected event:

Sub Connected()

Dim TheCache as MYSUBCLASSpgSQLcoreCache
TheCache = new MYSUBCLASSpgSQLcoreCache

TheCache.TargetSocket = me

TheCache.QueueSimpleQuery(<SomeSQL>)

End Sub


And here's your cache-subclass' DataReceived event:

Sub DataReceived(QueryName as String, RowCount as Integer,
ColumnCount as Integer)
//read the data aray here and do what you want to do next
End Sub


I hope this gets you started,

Marc

[Aliacta Support]

(You can work with a boolean property you ad to the App that you set
to True when you want to disconnect. You check then that property in
the While...Wend loop and disconnect there. -Marc)

[Aliacta Support]

Post by Aliacta Support
TheSocket.Connect
While TheSocket.IsConnected
App.DoEvents
Wend

You first have to wait until you *are* connected:

TheSocket.Connect

While Not TheSocket.IsConnected
App.DoEvents
Wend

While TheSocket.IsConnected
App.DoEvents
If App.booleanDisconnectionFlag then TheSocket.Disconnect
Wend


This should do it. (Of course you can create your cache and send the
query in between the two While...Wend loops now instead of from the
socket-subclass' Connected event.)

I haven't tried any of this and just am typing it as such but you get
the gist of it now I guess. If not, let me know.

Marc

[Jim Patek]

Post by Aliacta Support

Post by Aliacta Support
TheSocket.Connect
While TheSocket.IsConnected
App.DoEvents
Wend

TheSocket.Connect
While Not TheSocket.IsConnected
App.DoEvents
Wend
While TheSocket.IsConnected
App.DoEvents
If App.booleanDisconnectionFlag then TheSocket.Disconnect
Wend
This should do it. (Of course you can create your cache and send the
query in between the two While...Wend loops now instead of from the
socket-subclass' Connected event.)
I haven't tried any of this and just am typing it as such but you get
the gist of it now I guess. If not, let me know.
Marc
_______________________________________________
Postgresql mailing list
http://aliacta.com/mailman/listinfo/postgresql_aliacta.com

I had bumbled along enough to the the socket connected. I was having
problems getting the cache to work. I have tried a wait look like you
proposed but I get an error on the second App.DoEvents ans without that
statement I get and endless loop from this code:

Dim TheSocket as PgSocket
Dim TheCache as PgCache
Dim i As Integer

TheSocket = new PgSocket
TheCache = new PgCache

TheCache.TargetSocket = TheSocket

TheSocket.DatabaseName = "TBOX"
TheSocket.UserName = "postgres"
TheSocket.Password = "ubandit"
TheSocket.Port = 5432
TheSocket.Address = "192.168.0.126"

TheSocket.Connect

While Not TheSocket.IsConnected
App.DoEvents
Wend

While TheSocket.IsConnected
Print "Database Connected OK"
dataIn = False
TheCache.QueueSimpleQuery("SELECT
""CID"",""cgage"",""qflag"",""udate"",""uflag"",""xcoord"",""ycoord""
FROM ""system"".""UsgsCNT"" ;")
Exit
Wend

While Not dataIn
App.DoEvents
Wend

While dataIn
i = Ubound(TheCache.Data,1)
Print Str(i)
Wend



The dataIn boolean is set to true by the cache DataReceived event (or is
supposed to be anyway)

Jim

[Aliacta Support]

Post by Jim Patek

Post by Aliacta Support

Post by Aliacta Support
TheSocket.Connect
While TheSocket.IsConnected
App.DoEvents
Wend

TheSocket.Connect
While Not TheSocket.IsConnected
App.DoEvents
Wend
While TheSocket.IsConnected
App.DoEvents
If App.booleanDisconnectionFlag then TheSocket.Disconnect
Wend
This should do it. (Of course you can create your cache and send the
query in between the two While...Wend loops now instead of from the
socket-subclass' Connected event.)
I haven't tried any of this and just am typing it as such but you get
the gist of it now I guess. If not, let me know.
Marc
_______________________________________________
Postgresql mailing list
http://aliacta.com/mailman/listinfo/postgresql_aliacta.com

I had bumbled along enough to the the socket connected. I was having
problems getting the cache to work. I have tried a wait look like you
proposed but I get an error on the second App.DoEvents ans without that
Dim TheSocket as PgSocket
Dim TheCache as PgCache
Dim i As Integer
TheSocket = new PgSocket
TheCache = new PgCache
TheCache.TargetSocket = TheSocket
TheSocket.DatabaseName = "TBOX"
TheSocket.UserName = "postgres"
TheSocket.Password = "ubandit"
TheSocket.Port = 5432
TheSocket.Address = "192.168.0.126"
TheSocket.Connect
While Not TheSocket.IsConnected
App.DoEvents
Wend

(You should add a timeout to the loop above in case you supply wrong
connection parameters or the server is down etc.)

Post by Jim Patek
While TheSocket.IsConnected
Print "Database Connected OK"
dataIn = False
TheCache.QueueSimpleQuery("SELECT
""CID"",""cgage"",""qflag"",""udate"",""uflag"",""xcoord"",""ycoord""
FROM ""system"".""UsgsCNT"" ;")
Exit
Wend

You can replace the loop above with an If...Then

Post by Jim Patek
While Not dataIn
App.DoEvents
Wend
While dataIn
i = Ubound(TheCache.Data,1)
Print Str(i)
Wend

The loop above is endless...

(I presume you can replace it with an If...Then as well if getting
the Ubound is all you want.)

Marc

[Aliacta Support]

If you add a property App.Isconnecting you can do everything with
only one loop (and have only one App.DoEvents if multiple ones cause
you trouble):


Dim TheSocket as PgSocket
Dim TheCache as PgCache

TheSocket = new PgSocket
TheCache = new PgCache

TheCache.TargetSocket = TheSocket

TheSocket.DatabaseName = "TBOX"
TheSocket.UserName = "postgres"
TheSocket.Password = "ubandit"
TheSocket.Port = 5432
TheSocket.Address = "192.168.0.126"

App.IsConnecting = True
App.dataIn = False

TheSocket.Connect

While (TheSocket.IsConnected Or App.IsConnecting) And App.dataIn = False
App.DoEvents
If TheSocket.IsConnected AND App.IsConnecting Then
App.IsConnecting = False
Print "Database Connected OK"
TheCache.QueueSimpleQuery(MyQuery)
End If
Wend

Print Str(Ubound(TheCache.Data,1))

Return 0

[Aliacta Support]

The same, but with a timeout:


Dim TheSocket as PgSocket
Dim TheCache as PgCache
Dim Timout as Integer //Line added

TheSocket = new PgSocket
TheCache = new PgCache

TheCache.TargetSocket = TheSocket

TheSocket.DatabaseName = "TBOX"
TheSocket.UserName = "postgres"
TheSocket.Password = "ubandit"
TheSocket.Port = 5432
TheSocket.Address = "192.168.0.126"

App.IsConnecting = True
App.dataIn = False
Timeout = Ticks + 60 //Setting 1 second timeout to get connected

TheSocket.Connect

While (TheSocket.IsConnected Or App.IsConnecting) And App.dataIn = False
App.DoEvents
If TheSocket.IsConnected AND App.IsConnecting Then
App.IsConnecting = False
Print "Database Connected OK"
TheCache.QueueSimpleQuery(MyQuery)
Timeout = Ticks + 180 //Setting 3 second timeout to actually
perform the query
End If
If Ticks > Timeout Then
Print "Operation failed due to Timeout."
Return 1
End If
Wend

TheSocket.Disconnect //Line added. (It's cleaner to disconnect explicitly.)

Print Str(Ubound(TheCache.Data,1))

Return 0

[Jim Patek]

Post by Jim Patek
Dim TheSocket as PgSocket
Dim TheCache as PgCache
Dim Timout as Integer //Line added
TheSocket = new PgSocket
TheCache = new PgCache
TheCache.TargetSocket = TheSocket
TheSocket.DatabaseName = "TBOX"
TheSocket.UserName = "postgres"
TheSocket.Password = "ubandit"
TheSocket.Port = 5432
TheSocket.Address = "192.168.0.126"
App.IsConnecting = True
App.dataIn = False
Timeout = Ticks + 60 //Setting 1 second timeout to get connected
TheSocket.Connect
While (TheSocket.IsConnected Or App.IsConnecting) And App.dataIn = False
App.DoEvents
If TheSocket.IsConnected AND App.IsConnecting Then
App.IsConnecting = False
Print "Database Connected OK"
TheCache.QueueSimpleQuery(MyQuery)
Timeout = Ticks + 180 //Setting 3 second timeout to actually
perform the query
End If
If Ticks > Timeout Then
Print "Operation failed due to Timeout."
Return 1
End If
Wend
TheSocket.Disconnect //Line added. (It's cleaner to disconnect explicitly.)
Print Str(Ubound(TheCache.Data,1))
Return 0
_______________________________________________
Postgresql mailing list
http://aliacta.com/mailman/listinfo/postgresql_aliacta.com

Both versions crash on the App.DoEvents. You get an "Out of Bounds
Exception was not handled" message and an error code of 0. No
indication of exactly what is out of bounds.

jim

[Aliacta Support]

Post by Jim Patek
Both versions crash on the App.DoEvents.

This is weird. App.DoEvents was created for console apps. What
happens if you just leave it out?

[Aliacta Support]

Post by Aliacta Support

Post by Jim Patek
Both versions crash on the App.DoEvents.

This is weird. App.DoEvents was created for console apps. What
happens if you just leave it out?

I'm on a Mac and you're on Windows and the final result must run on
Linux so you'd better check the behavior on the latter as well,
assuming that it works without App.DoEvents on Windows.

[Aliacta Support]

Apparently the behavior in RB2007 has changed a bit compared to a
while back and you can't call App.DoEvents anymore once you're
connected.

Here's code that works for me:

Function Run(args() as String) As Integer

Dim TheSocket as pgSQLcoreSocket
Dim TheCache as MYSUBCLASSpgSQLcoreCache
Dim Timeout as double //Line added
Dim IsConnecting as Boolean

TheSocket = new pgSQLcoreSocket
TheCache = new MYSUBCLASSpgSQLcoreCache

TheCache.TargetSocket = TheSocket

TheSocket.DatabaseName = "mydatabase"
TheSocket.UserName = "postgres"
TheSocket.Password = ""
TheSocket.Port = 5432
TheSocket.Address = "localhost"

IsConnecting = True
App.dataIn = False
Timeout = Microseconds + 1000000 //Setting 1 second timeout to get connected

TheSocket.Connect

While (TheSocket.IsConnected Or IsConnecting) And App.dataIn = False
If TheSocket.IsConnected AND IsConnecting Then
IsConnecting = False
Print "Database Connected OK"
TheCache.QueueSimpleQuery("SELECT * FROM mytable")
Timeout = Microseconds + 3000000 //Setting 3 second timeout to
actually perform the query
Else
App.DoEvents
End If
If Microseconds > Timeout Then
Print "Operation failed due to Timeout."
If TheSocket.IsConnected Then TheSocket.Disconnect
Return 1
End If
Wend

TheSocket.Disconnect

Print Str(Ubound(TheCache.Data,1))

Return 0

End Function

[Aliacta Support]

Jim,

I notice that the disconnecting may still cause some problem, i.e.
the application returns while the socket is till busy disconnecting,
which apparently throws an out of bounds error. I guess the socket
is already destroyed while it still receives commands.

Not calling socket.disconnect has no real impact on PostgreSQL. It
will believe you're still connected for a little while so it would
only matter in a case where you get to the maximum limit of
simultaneous connections. (It will log an error for your dirty
disconnection.)

If you still want to disconnect in a clean way you have to do so
again with a While...Wend loop wiht App.DoEvents in it, and best put
your Timeout in it again as well.

Cheers,

Marc

[Jim Patek]

Post by Aliacta Support
Jim,
I notice that the disconnecting may still cause some problem, i.e.
the application returns while the socket is till busy disconnecting,
which apparently throws an out of bounds error. I guess the socket
is already destroyed while it still receives commands.
Not calling socket.disconnect has no real impact on PostgreSQL. It
will believe you're still connected for a little while so it would
only matter in a case where you get to the maximum limit of
simultaneous connections. (It will log an error for your dirty
disconnection.)
If you still want to disconnect in a clean way you have to do so
again with a While...Wend loop wiht App.DoEvents in it, and best put
your Timeout in it again as well.
Cheers,
Marc
_______________________________________________
Postgresql mailing list
http://aliacta.com/mailman/listinfo/postgresql_aliacta.com

Yes, I noticed that I got that "Out of Bounds" error from the socket
disconnect. I moved that statement after the Print of the Ubound of the
cache data array. It says the the Ubound is -1 and, in fact, the cache
is still empty.

Jim

[Aliacta Support]

There's definitely something fishy going on here with console apps in
RB2007. I can run the app we made (Jim and me on the mailing list) a
number of times and it will throw me seemingly random errors.

Dane, are you still on 5.5?

Marc

[Aliacta Support]

As far as I can see it gives the out of bounds when there allegedly
isn't a cache for the socket to report to.

[Jason Moehlman]

Hello,

I may have some input on this, at the very least a work around. I
have console apps that work great with 2007R1.

During my conversion to the v2 beta's I had a lot of trouble with a
lot of the same errors, weird behavior, etc.

Through lots of list help from Marc, and a lot of trial and error I
found that the pgsock.connect method sets pgsock.isconnected way
before it is actually connected and capable of running a query.

I thought it was normal and simply created a system that uses a timer
to work around it. I realize that your web application is
performance sensitive for connect times, but this should help you get
it working.

I found that I could only connect and run query's after the connected
event of the socket fires. before that even if the isConnected
property is true, it is really not connected and fully capable of
running queries, trying to run a query before the pgsock.connected
event fires gets everything all mucked up.

So...

create a new boolean property in the socket, default value of false.
In the connected event of the new socket set the new property to true.

in the app.run code after calling the socket.connect, check for the
new property being set to true, not socket.isconnected.

once it is true, you should be able to run your query without errors.

...connect setup code...license, connection stuff, etc.

newSocket.NewConnected=false
newSocket.Connect

While not newSocket.NewConnected
App.DoEvents
Wend

....Do Query Here...

end

Another simple way to test is to move your cache and query code into
the connected event of the socket. I think that is how I found this
originally.

I hope this helps, it drove me crazy for a long time and I almost
quit using pgsqlrb. I am really glad I didn't!

Jason Moehlman
Linux Software Labs Inc.

[Aliacta Support]

Thanks Jason,

I'm glad you chimed in because I didn't remember this detail anymore
while I should have.
TCPSocket.IsConnected is indeed a bad time to send the query! It's
at IsConnected AND has authenticated, hence in the Connected event,
that everything has to be started.

I'll make sure I'll make this clear in the final version of the
manual. And perhaps I'll roll pgSQL4RB's own IsConnected property
instead of using the one from its Super, TCPSocket.

Cheers,

Marc

Post by Jason Moehlman
Hello,
I may have some input on this, at the very least a work around. I
have console apps that work great with 2007R1.
During my conversion to the v2 beta's I had a lot of trouble with a
lot of the same errors, weird behavior, etc.
Through lots of list help from Marc, and a lot of trial and error I
found that the pgsock.connect method sets pgsock.isconnected way
before it is actually connected and capable of running a query.
I thought it was normal and simply created a system that uses a timer
to work around it. I realize that your web application is
performance sensitive for connect times, but this should help you get
it working.
I found that I could only connect and run query's after the connected
event of the socket fires. before that even if the isConnected
property is true, it is really not connected and fully capable of
running queries, trying to run a query before the pgsock.connected
event fires gets everything all mucked up.
So...
create a new boolean property in the socket, default value of false.
In the connected event of the new socket set the new property to true.
in the app.run code after calling the socket.connect, check for the
new property being set to true, not socket.isconnected.
once it is true, you should be able to run your query without errors.
...connect setup code...license, connection stuff, etc.
newSocket.NewConnected=false
newSocket.Connect
While not newSocket.NewConnected
App.DoEvents
Wend
....Do Query Here...
end
Another simple way to test is to move your cache and query code into
the connected event of the socket. I think that is how I found this
originally.
I hope this helps, it drove me crazy for a long time and I almost
quit using pgsqlrb. I am really glad I didn't!
Jason Moehlman
Linux Software Labs Inc.
_______________________________________________
Postgresql mailing list
http://aliacta.com/mailman/listinfo/postgresql_aliacta.com

[Jim Patek]

Thanks, Jason. I could swear that we (Marc and I ) tried that several
times last night, but when I followed your instructions, it worked.
Perhaps I'll go back and see if I can figure out why it didn't work
before (what I was doing differently), but for now I'll just take the
miracle on faith and march (stumble,?) forward. Thanks again for your help.

Jim Patek

Post by Jason Moehlman
Hello,
I may have some input on this, at the very least a work around. I
have console apps that work great with 2007R1.
During my conversion to the v2 beta's I had a lot of trouble with a
lot of the same errors, weird behavior, etc.
Through lots of list help from Marc, and a lot of trial and error I
found that the pgsock.connect method sets pgsock.isconnected way
before it is actually connected and capable of running a query.
I thought it was normal and simply created a system that uses a timer
to work around it. I realize that your web application is
performance sensitive for connect times, but this should help you get
it working.
I found that I could only connect and run query's after the connected
event of the socket fires. before that even if the isConnected
property is true, it is really not connected and fully capable of
running queries, trying to run a query before the pgsock.connected
event fires gets everything all mucked up.
So...
create a new boolean property in the socket, default value of false.
In the connected event of the new socket set the new property to true.
in the app.run code after calling the socket.connect, check for the
new property being set to true, not socket.isconnected.
once it is true, you should be able to run your query without errors.
...connect setup code...license, connection stuff, etc.
newSocket.NewConnected=false
newSocket.Connect
While not newSocket.NewConnected
App.DoEvents
Wend
....Do Query Here...
end
Another simple way to test is to move your cache and query code into
the connected event of the socket. I think that is how I found this
originally.
I hope this helps, it drove me crazy for a long time and I almost
quit using pgsqlrb. I am really glad I didn't!
Jason Moehlman
Linux Software Labs Inc.
_______________________________________________
Postgresql mailing list
http://aliacta.com/mailman/listinfo/postgresql_aliacta.com

[Aliacta Support]

Post by Jim Patek
Perhaps I'll go back and see if I can figure out why it didn't work
before (what I was doing differently), but for now I'll just take the
miracle on faith and march (stumble,?) forward.

Hi Jim,

I don't think you'll stumble anymore. Jason pointed out what I
should have thought about myself immediately:

pgSQLcoreSocket.IsConnected is the same as its Super:
TCPSocket.IsConnected. However this means that IsConnected is true
as soon as a TCP connection with PostgreSQL is established, but
that's before you've authenticated. So you can't start sending
queries quite yet.

The pgSQLcoreSocket.Connected event however is triggered after the
authentication and initialization, when you are truly ready to start
sending queries.

The very first sample code I sent you where the cache is created in
the socket's Connected event should have worked, all other sample
code I sent relied on the IsConnected property and thus caused the
weird behavior.

I'll most likely add an IsConnected property of its own to the
pgSQLcoreSocket that will be consistent with the Connected event. I
can now see how interesting this can be to console application
developers. ;-)

(The sample GUI code you sent me probably has the same issue.)

Happy coding,

Marc.

PS: it would be fun if you'd let us know how much faster your tasks
are performed now that you've switched to pgSQL4RB.

[Jason Moehlman]

Your welcome!

I am happy that it worked for you.

I am interested in how it turns out also. I have one idea/need for a
CGI program in RB, but I was concerned about performance under load
so I have not taken the time to move the project forward.

Any feedback of the RB vs C version on your Apache/Linux server would
be appreciated.

Good Luck with your project.

Jason

Post by Jim Patek
Thanks, Jason. I could swear that we (Marc and I ) tried that several
times last night, but when I followed your instructions, it worked.
Perhaps I'll go back and see if I can figure out why it didn't work
before (what I was doing differently), but for now I'll just take the
miracle on faith and march (stumble,?) forward. Thanks again for your help.
Jim Patek

[Aliacta Support]

Post by Jason Moehlman
Any feedback of the RB vs C version on your Apache/Linux server would
be appreciated.

Hi jason,

I tested C against RB (for GUI apps) in the early days of pgSQL4RB.
They were close enough matches to be undistinguishable speed-wise.

However the performance of parsing, the heaviest job inside pgSQL4RB,
has varied between RB releases. If I recollect well enough, around
RB 5.5 it took a 10% hit but then with RB 2006 it was very fast
again, if not faster than originally. I haven't been testing with RB
2007. It's a bit of a futile exercise anyway since the speed can
vary wildly between RB point releases and you're going to use the RB
release that has the features and stability you need anyway,
regardless of the speed.

I'm fairly confident you can use RB for any CGI work though because
it really is a fast language without the GUI layer, and you're nearly
independent from features. There isn't much difference feature-wise
between RB 5.5 and 2007 for writing CGIs--correct me if I'm wrong.

All pgSQL4RB does is moving memoryblocks around in a fancy--and
highly intelligent :-) --way. Internally I'd think RB is just
playing with a couple of pointers and that's it.

You'd only have to compile your CGI with a variety of RB releases and
check for speed anomalies between them, if any. I'm very confident a
fast RB version would hold up against C. And the ease of development
would make it worth using RB.

(Should you have to do heavy lifting with strings then there's always
Elf-Data. But if you're just moving records in and out you don't
need it.)

Checking for speed anomalies is really easy too with pgSQL4RB's
performance report feature.

Marc

[Jason Moehlman]

Thank you very much for the information. I am looking forward to
trying this out.

Jason

Post by Aliacta Support

Post by Jason Moehlman
Any feedback of the RB vs C version on your Apache/Linux server would
be appreciated.

Hi jason,
I tested C against RB (for GUI apps) in the early days of pgSQL4RB.
They were close enough matches to be undistinguishable speed-wise.
However the performance of parsing, the heaviest job inside pgSQL4RB,
has varied between RB releases. If I recollect well enough, around
RB 5.5 it took a 10% hit but then with RB 2006 it was very fast
again, if not faster than originally. I haven't been testing with RB
2007. It's a bit of a futile exercise anyway since the speed can
vary wildly between RB point releases and you're going to use the RB
release that has the features and stability you need anyway,
regardless of the speed.
I'm fairly confident you can use RB for any CGI work though because
it really is a fast language without the GUI layer, and you're nearly
independent from features. There isn't much difference feature-wise
between RB 5.5 and 2007 for writing CGIs--correct me if I'm wrong.
All pgSQL4RB does is moving memoryblocks around in a fancy--and
highly intelligent :-) --way. Internally I'd think RB is just
playing with a couple of pointers and that's it.
You'd only have to compile your CGI with a variety of RB releases and
check for speed anomalies between them, if any. I'm very confident a
fast RB version would hold up against C. And the ease of development
would make it worth using RB.
(Should you have to do heavy lifting with strings then there's always
Elf-Data. But if you're just moving records in and out you don't
need it.)
Checking for speed anomalies is really easy too with pgSQL4RB's
performance report feature.
Marc
_______________________________________________
Postgresql mailing list
http://aliacta.com/mailman/listinfo/postgresql_aliacta.com

[Jim Patek]

So far I have the 2 CGI programs that interface between the data
(PostgreSQL now) and Apache/MapServer converted to RealBasic. The
original CGIs were written in C for one and Fortran95 for the other. If
there is a speed difference, it isn't apparent. Perhaps if I were to
include timers, but C/Fortran95/RealBasic all are plenty fast enough to
do this job.

The backend programs that I am working on now are a different story
however. The backend fires a web robot that gathers new data (from the
USGS in the program I'm working on now), stores it in temporary storage,
calculates "period of record" statistics for each gage, creates a
"complete" record for 1980 to present for each gage by filling the gaps
in data using regression equations (linear, log-linear, exponential, and
power curve) it has developed for surrounding (within150 km) gages.
After that it uses the "filled" or "complete" to project flow records
and stats to location without flow gages via a modified NRCS curve
equation and a good bit of GIS based data.

The original backend is written in Fortran95 (you probably guessed that
I'm and engineer) and is WAY faster than the RB version. That said, I
should qualify a few things. The original is not working off a SQL
server ... all its data are stored in binary random access files
maintained by the Fortran based system. There is a lot of math
involved, including array processing and matrix algebra. RB is capable
of the math, but is VERY slow compared to Fortran95. Of course the
primary purpose of Fortran is math and it has native array and matrix
handling built into the language.

The reason for moving away from the Fortran based system was to convert
to a SQL server data manager to make it easier to maintain the data
(adding 1 parameter to the old system required a lot of re-programming,
OK for a prototype but not "ready for prime time"). Even though the RB
is slower (mostly due to the math and array handling requirements of the
system) it's fast enough, since updates, to this part of the system
anyway, only happen once or twice a year.

Converting to pgSQL4RB from the RB PostgreSQL plugin has sped thing up.
Don't know exactly how much since I didn't bother to finish the plugin
based app (too slow). I would estimate that the pgSQL4RB version is 2
times faster until I implemented the COPY from STDIN with pgSQL4RB where
I am writing 10 to 20 K records repeatedly. Now it's at least an order
of magnitude faster than the plugin. The difference would probably be
higher, but the bulk of the runtime is spent crunching numbers.

Oh, yeah. Don't know if it makes a difference but the developmental box
runs Slackware 11, Apache 1.3.37, PostgreSQL 8.1.5, and MapServer
4.10.0 on a Shuttle box with an AMD Athlon 2100 (I think) and 1 gig of RAM.

Jim

Post by Jason Moehlman
Your welcome!
I am happy that it worked for you.
I am interested in how it turns out also. I have one idea/need for a
CGI program in RB, but I was concerned about performance under load
so I have not taken the time to move the project forward.
Any feedback of the RB vs C version on your Apache/Linux server would
be appreciated.
Good Luck with your project.
Jason

Post by Jim Patek
Thanks, Jason. I could swear that we (Marc and I ) tried that several
times last night, but when I followed your instructions, it worked.
Perhaps I'll go back and see if I can figure out why it didn't work
before (what I was doing differently), but for now I'll just take the
miracle on faith and march (stumble,?) forward. Thanks again for your help.
Jim Patek

_______________________________________________
Postgresql mailing list
http://aliacta.com/mailman/listinfo/postgresql_aliacta.com

[Aliacta Support]

Post by Jim Patek
Now it's at least an order
of magnitude faster than the plugin. The difference would probably be
higher, but the bulk of the runtime is spent crunching numbers.

I don't know how much of your math could be done inside PostgreSQL.
It's worth investgating because you'd both have faster math and less
exports.

The only backdraw would be in terms of maintenance where you'd
probably have your math split up over RB and PostgreSQL.

Marc

[Jim Patek]

Post by Aliacta Support
There's definitely something fishy going on here with console apps in
RB2007. I can run the app we made (Jim and me on the mailing list) a
number of times and it will throw me seemingly random errors.
Dane, are you still on 5.5?
Marc
_______________________________________________
Postgresql mailing list
http://aliacta.com/mailman/listinfo/postgresql_aliacta.com

It may not be limited to console apps. I have been converting some of
the app I was building to a desktop app and I occasionally run into the
same or a similar problem. Perhaps it would be cleared it I start at
the beginning.
I am converting a GIS/Database application I wrote that operates as a
CGI program under Apache on Linux. The application was originally
written in Fortran 95 and C. However, I want to wean the application
off of my own binary file based data handling to a RDBMS (PostgreSQL).
I have been programming off and on with RealBasic for a couple of years
now and chose it for the cross-platform capability.

The CGI programs that link the PostgreSQL to Apache (via MapServer) are
written with the PostgreSQL RB plugin and work fine (they only perform a
single data request for small amounts of data per CGI call). The part I
am working on now is part of the backend to this system. A web robot
that is also part of the system occasionally frisks several online
databases for updates to data (USGS, EPA, States of Arkansas, Oklahoma,
and Texas). When if finds new stuff is downloads it to temporary space
and schedules a update (in the wee hours of the morning). The one I
have been working on if for USGS flow data, so when it updates the
program pulls data from several tables in the PgSQL database, several
thousand flow records for an individual gage, performs a bunch of
statistics and updates the pertinent rows in the proper tables
(hopefully). It has to do this unattended. I don't really need
multithreading since the data from each of the record retrievals must be
present to do the statistics and then the updates can be written back.
I actually have this working with the RB PgSQL plugin, except that it
UNBELIEVABLY slow. The trouble I have is to make sure the data are
there before performing the next step. Sometimes the logic flag the is
supposed to be updated when the DataRecieved event is triggered is set
to True, but the cache is empty. Bad things happen as a result. This
is very similar to the situation we have been dealing with today on the
console app (It would be best if this were a console app).

Thats probably way more than you wanted to know, but I will have to make
a decision soon about how to go about this, since the client is
expecting some progress soon.

thanks
Jim

[Aliacta Support]

Post by Jim Patek
Sometimes the logic flag the is
supposed to be updated when the DataRecieved event is triggered is set
to True, but the cache is empty.

As an experiment, I've modified the code in pgSQL4RB so it would be
impossible for the DataReceived event to be triggered yet the flag is
still set to true! (I've also put a Print command in the
DataREceived event together with the dataIn = True but no printing
happens!)

Post by Jim Patek
Bad things happen as a result.

yep

I have seen this happen once before though during some RB beta cycle,
probably 2 years ago. I called it time traveling if I remember
correctly because events seemed to be triggered in random order, if
you search the NUG perhaps you'll find that post.

Let's see if it works without using the flag, i.e. by putting all the
code in the event itself.

[Aliacta Support]

Post by Jim Patek
It may not be limited to console apps.

I haven't seen anything strange with GUI apps. If you could send me
a simplified GUI project that shows anomalies I'd be very interested
in looking into that. (Bad use of App.DoEvents in a GUI app can
create any weird behavior, though. it would have to be without that.)

[Aliacta Support]

Post by Aliacta Support
If Ticks > Timeout Then
Print "Operation failed due to Timeout."

If TheSocket.IsConnected Then TheSocket.Disconnect

Post by Aliacta Support
Return 1
End If

[Dane Hansen]

Opps sent this to marc and not the list

Post by Aliacta Support
Dane, are you still on 5.5?

I have been in 2006/7 gui mode for a while.
no problems there
I think the early RBv6 worked for console apps
I will try some in 2007 tomorrow i dont have rb with me
I think most of my console apps use the run event to set things up
and the socket and cache subclasses drive the rest
(the other use threads. you don't want that)
These would be properties of the app
TheSocket as MYSUBCLASSpgSQLcoreSocket
TheCache as MYSUBCLASSpgSQLcoreCache
Finished as Boolean
### app
Function app.Run
App.TheSocket = new pgSQLcoreSocket
App.TheCache = new MYSUBCLASSpgSQLcoreCache
App.TheCache.TargetSocket = TheSocket
App.TheSocket.DatabaseName = "mydatabase"
App.TheSocket.UserName = "postgres"
App.TheSocket.Password = ""
App.TheSocket.Port = 5432
App.TheSocket.Address = "localhost"
Print "TheSocket Connecting..."
App.TheSocket.Connect
While Not App.Finished
DoEvents
Wend
// I don't usualy bother with this as the app will terminate
before this happens
TheSocket.Disconnect
Return 0
End Function
Sub app.SocketReady
Print "Database Connected OK"
TheCache.QueueSimpleQuery("SELECT * FROM mytable", "get_data")
End Sub
Sub app.QueryDone(QueryName as String)
Select Case QueryName
Case "get_data"
Print Str(Ubound(TheCache.Data,1))
App.Finished
Else
Print "Query '"+QueryName+"' unknown!"
Return 1
End Select
End Sub
### TheSocket
Sub TheSocket.Connected()
App.SocketReady
End Sub
### TheCache
Sub TheCache.DataRecived()
App.QueryDone me.QueryName
End Sub
This way is much easier when you start getting a lot of data doing
lots of different things
I usualy don't time out cause i can control c
I will try it in 2007 tonight if i get time
Dane

Post by Aliacta Support
There's definitely something fishy going on here with console apps
in RB2007. I can run the app we made (Jim and me on the mailing
list) a number of times and it will throw me seemingly random errors.
Dane, are you still on 5.5?
Marc