1. Any PB & ADO gurus?
You were so helpful for me before (thx Jason) I was hoping someone might
get me unstuck again so I can get to the fun part of writing code.
A little background. I bought PowerBASIC years ago because I wanted a
good compiler. But I find PB to be both ugly and incomplete.
While I've always liked the core C language, I find it gets dirty quickly.
Euphoria is very clean and well named. It is euphoric writing code
with such a flexible data type and it isn't cluttered with a lot of junk.
Anyway, to my issue; Here's the PB (double ugly IMHO) code...
FUNCTION dbOpen ALIAS "dbOpen" (sPath AS ASCIIZ) EXPORT AS LONG
DIM v1 AS VARIANT
ON ERROR GOTO ErrorTrap
LET m_db = NEW DISPATCH IN "ADODB.Connection.2.7"
LET m_rs = NEW DISPATCH IN "ADODB.Recordset.2.7"
MSGBOX "CommandTimeout start" 'debug code
v1 = 120
OBJECT LET m_db.CommandTimeout = v1
MSGBOX "CommandTimeout done" 'debug code
v1 = 3 '%ado_Use_Client
OBJECT LET m_db.CursorLocation = v1
v1 = "Provider=Microsoft.Jet.OLEDB.4.0; " _
& "Data Source=" & sPath & "; " _
& "User ID=ADMIN; " _
& "Password=;"
OBJECT LET m_db.ConnectionString = v1
OBJECT CALL m_db.Open
dbOpen = 1 'success
EXIT FUNCTION
ErrorTrap:
dbOpen = 0 'failure
LET m_db = NOTHING
END FUNCTION
-----------------------------------------------------
When I originally wrote this the param sPath was AS STRING, but Euphoria's
allocate_string produces the PB type ASCIIZ so I changed that.
This code works fine called from PB, but when called from Euphoria it
fails on the line... OBJECT LET m_db.CommandTimeout = v1
I added the two messageboxes to bracket the problem. Called from
Euphoria it never gets to the second messagebox.
I'm baffled since disregarding the ugly syntax the line is pretty
straight forward. Any ideas?
Alternately, does anyone have another way of using ADO recordset
from Euphoria? It would be nice if I could access any SQL db with
just a new connection string as I can with this code.
Why not use an EDB (anticipating your question) db? A number of reasons,
basically because I know how to do safe multiuser calls to a SQL db,
but don't see how that would work with an EDB. I'd be interested in
that question as well. Hey, I'm interested in lots of things... 
2. Re: Any PB & ADO gurus?
- Posted by Michael J. Sabal <m_sabal at yah?o.?om>
May 24, 2008
-
Last edited May 25, 2008
ken mortenson wrote:
>
> Alternately, does anyone have another way of using ADO recordset
> from Euphoria? It would be nice if I could access any SQL db with
> just a new connection string as I can with this code.
>
> Why not use an EDB (anticipating your question) db? A number of reasons,
> basically because I know how to do safe multiuser calls to a SQL db,
> but don't see how that would work with an EDB. I'd be interested in
> that question as well. Hey, I'm interested in lots of things...
Why not use ODBC?
3. Re: Any PB & ADO gurus?
- Posted by Bernie Ryan <xotron at blue?ro?.com>
May 24, 2008
-
Last edited May 25, 2008
ken mortenson wrote:
>
> You were so helpful for me before (thx Jason) I was hoping someone might
> get me unstuck again so I can get to the fun part of writing code.
>
> A little background. I bought PowerBASIC years ago because I wanted a
> good compiler. But I find PB to be both ugly and incomplete.
>
> While I've always liked the core C language, I find it gets dirty quickly.
>
> Euphoria is very clean and well named. It is euphoric writing code
> with such a flexible data type and it isn't cluttered with a lot of junk.
>
> Anyway, to my issue; Here's the PB (double ugly IMHO) code...
>
> FUNCTION dbOpen ALIAS "dbOpen" (sPath AS ASCIIZ) EXPORT AS LONG
> DIM v1 AS VARIANT
> ON ERROR GOTO ErrorTrap
>
> LET m_db = NEW DISPATCH IN "ADODB.Connection.2.7"
> LET m_rs = NEW DISPATCH IN "ADODB.Recordset.2.7"
>
> MSGBOX "CommandTimeout start" 'debug code
> v1 = 120
> OBJECT LET m_db.CommandTimeout = v1
> MSGBOX "CommandTimeout done" 'debug code
>
> v1 = 3 '%ado_Use_Client
> OBJECT LET m_db.CursorLocation = v1
> v1 = "Provider=Microsoft.Jet.OLEDB.4.0; " _
> & "Data Source=" & sPath & "; " _
> & "User ID=ADMIN; " _
> & "Password=;"
> OBJECT LET m_db.ConnectionString = v1
> OBJECT CALL m_db.Open
> dbOpen = 1 'success
> EXIT FUNCTION
>
> ErrorTrap:
> dbOpen = 0 'failure
> LET m_db = NOTHING
> END FUNCTION
> -----------------------------------------------------
> When I originally wrote this the param sPath was AS STRING, but Euphoria's
> allocate_string produces the PB type ASCIIZ so I changed that.
>
> This code works fine called from PB, but when called from Euphoria it
> fails on the line... OBJECT LET m_db.CommandTimeout = v1
>
> I added the two messageboxes to bracket the problem. Called from
> Euphoria it never gets to the second messagebox.
>
> I'm baffled since disregarding the ugly syntax the line is pretty
> straight forward. Any ideas?
>
> Alternately, does anyone have another way of using ADO recordset
> from Euphoria? It would be nice if I could access any SQL db with
> just a new connection string as I can with this code.
>
> Why not use an EDB (anticipating your question) db? A number of reasons,
> basically because I know how to do safe multiuser calls to a SQL db,
> but don't see how that would work with an EDB. I'd be interested in
> that question as well. Hey, I'm interested in lots of things...
ken:
Did you look in the archive there are SQL and ODBC database programs here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=ODBC+Database+Connectivity
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
4. Re: Any PB & ADO gurus?
- Posted by don cole <doncole at ?acbell.ne?>
May 24, 2008
-
Last edited May 25, 2008
ken mortenson wrote:
>
> You were so helpful for me before (thx Jason) I was hoping someone might
> get me unstuck again so I can get to the fun part of writing code.
>
> A little background. I bought PowerBASIC years ago because I wanted a
> good compiler. But I find PB to be both ugly and incomplete.
>
> While I've always liked the core C language, I find it gets dirty quickly.
>
> Euphoria is very clean and well named. It is euphoric writing code
> with such a flexible data type and it isn't cluttered with a lot of junk.
>
> Anyway, to my issue; Here's the PB (double ugly IMHO) code...
>
> FUNCTION dbOpen ALIAS "dbOpen" (sPath AS ASCIIZ) EXPORT AS LONG
> DIM v1 AS VARIANT
> ON ERROR GOTO ErrorTrap
>
> LET m_db = NEW DISPATCH IN "ADODB.Connection.2.7"
> LET m_rs = NEW DISPATCH IN "ADODB.Recordset.2.7"
>
> MSGBOX "CommandTimeout start" 'debug code
> v1 = 120
> OBJECT LET m_db.CommandTimeout = v1
> MSGBOX "CommandTimeout done" 'debug code
>
> v1 = 3 '%ado_Use_Client
> OBJECT LET m_db.CursorLocation = v1
> v1 = "Provider=Microsoft.Jet.OLEDB.4.0; " _
> & "Data Source=" & sPath & "; " _
> & "User ID=ADMIN; " _
> & "Password=;"
> OBJECT LET m_db.ConnectionString = v1
> OBJECT CALL m_db.Open
> dbOpen = 1 'success
> EXIT FUNCTION
>
> ErrorTrap:
> dbOpen = 0 'failure
> LET m_db = NOTHING
> END FUNCTION
> -----------------------------------------------------
> When I originally wrote this the param sPath was AS STRING, but Euphoria's
> allocate_string produces the PB type ASCIIZ so I changed that.
>
> This code works fine called from PB, but when called from Euphoria it
> fails on the line... OBJECT LET m_db.CommandTimeout = v1
>
> I added the two messageboxes to bracket the problem. Called from
> Euphoria it never gets to the second messagebox.
>
> I'm baffled since disregarding the ugly syntax the line is pretty
> straight forward. Any ideas?
>
> Alternately, does anyone have another way of using ADO recordset
> from Euphoria? It would be nice if I could access any SQL db with
> just a new connection string as I can with this code.
>
> Why not use an EDB (anticipating your question) db? A number of reasons,
> basically because I know how to do safe multiuser calls to a SQL db,
> but don't see how that would work with an EDB. I'd be interested in
> that question as well. Hey, I'm interested in lots of things...
Hello Ken,
I am not familiar with PB but did kinow Liberty Basic.
I found the best way was to forget all about Liberty Basic and start all over
with Euphoria. It's was much easier and faster that way.
This is just my 2 cents worth.
Don Cole
5. Re: Any PB & ADO gurus?
Michael J. Sabal wrote:
>Why not use ODBC?
Bernie Ryan wrote:
>Did you look in the archive...
don cole wrote:
>I found the best way [is to] start all over with Euphoria.
Thanks for the responses guys. I haven't used ODBC in over ten years, in
VB6 I pulled info from ODBC and just did direct ADO. If I remember it was
because of the performance hit using ODBC. Bernie, in the time honored
tradition of programmers everywhere, I was trying to be lazy and here you
give me homework to do
Don, I've been looking for over thirty years for the 'ONE TRUE LANGUAGE' a
bit like Don Quixote. I'm a true believer because I see glimpses of it
and know I in theory could get what I want. Euphoria is so close, but it
continues in some traditions that I am dead set against.
Don ya push my button and I feel a rant coming on...
I hesitate to commit to Euphoria partly because I would never deliver a
product I couldn't be confident in. This DLL I wrote works and I've used
it, but for reasons I don't understand, it blows up when called from
Euphoria. Not that it's Euphoria's fault, frankly I'm amazed I was able
to use an ADO object from PowerBASIC at all. I wasn't expecting it to work,
but it did and has been rock solid in several other projects I've done.
PowerBASIC is out, because although it does some things I need, it's ugly
(which makes it difficult to read) and doesn't do all that I need.
Another thing (again not the fault of Euphoria) is I wrote a windows program
right after my skipper submission using win32lib. When I updated to a newer
version of win32lib my program didn't work anymore. So I won't use win32lib
because I don't trust it to not break my program in the future. I've had
this problem with updated controls for VB6 as well. I don't buy those
controls anymore either. Now I just write my own (where I can.)
People have ideas all over the map. This discussion of namespaces caught my
interest because it's a good example of solving the wrong problem. Name
collisions don't happen with the right scoping rules. OOP is overhyped,
but being able to create instances of a class completely eliminates this
problem in a way that makes enterprise level development very managable.
I maintained over a million lines of VB6 code (by myself during some of
it's ten year life) which I couldn't have done without the project's file
level scoping rules and the IDE allowing me to immediately drill down to
the definition of any routine or variable in two clicks. Having to search
for the declarations with no idea of what file it's in ridiculously slows
down productivity. You demonstrate a problem in a program I've never seen
before written in VB6 and I can track it down in the code in just a few
seconds (it may take longer to actually fix the problem, but finding it is
usually trivial.) I can't live without that anymore. I'm old and cranky.
... and that's the end of my rant.
ken.
Now I've got to do the homework Bernie gave me.... sheesh...
6. Re: Any PB & ADO gurus?
ken mortenson wrote:
>
> Michael J. Sabal wrote:
> >Why not use ODBC?
>
> Bernie Ryan wrote:
> >Did you look in the archive...
>
> don cole wrote:
> >I found the best way [is to] start all over with Euphoria.
>
> Thanks for the responses guys. I haven't used ODBC in over ten years, in
> VB6 I pulled info from ODBC and just did direct ADO. If I remember it was
> because of the performance hit using ODBC. Bernie, in the time honored
> tradition of programmers everywhere, I was trying to be lazy and here you
> give me homework to do
>
> Don, I've been looking for over thirty years for the 'ONE TRUE LANGUAGE' a
> bit like Don Quixote. I'm a true believer because I see glimpses of it
> and know I in theory could get what I want. Euphoria is so close, but it
> continues in some traditions that I am dead set against.
>
> Don ya push my button and I feel a rant coming on...
>
> I hesitate to commit to Euphoria partly because I would never deliver a
> product I couldn't be confident in. This DLL I wrote works and I've used
> it, but for reasons I don't understand, it blows up when called from
> Euphoria. Not that it's Euphoria's fault, frankly I'm amazed I was able
> to use an ADO object from PowerBASIC at all. I wasn't expecting it to work,
> but it did and has been rock solid in several other projects I've done.
>
> PowerBASIC is out, because although it does some things I need, it's ugly
> (which makes it difficult to read) and doesn't do all that I need.
>
> Another thing (again not the fault of Euphoria) is I wrote a windows program
> right after my skipper submission using win32lib. When I updated to a newer
> version of win32lib my program didn't work anymore. So I won't use win32lib
> because I don't trust it to not break my program in the future.
This could easly be fixed with
include win32lib_ver3.2.exw
include win32lib_ver4.exw
etc...
I've had
> this problem with updated controls for VB6 as well. I don't buy those
> controls anymore either. Now I just write my own (where I can.)
>
> People have ideas all over the map. This discussion of namespaces caught my
> interest because it's a good example of solving the wrong problem. Name
> collisions don't happen with the right scoping rules. OOP is overhyped,
> but being able to create instances of a class completely eliminates this
> problem in a way that makes enterprise level development very managable.
>
> I maintained over a million lines of VB6 code (by myself during some of
> it's ten year life) which I couldn't have done without the project's file
> level scoping rules and the IDE allowing me to immediately drill down to
> the definition of any routine or variable in two clicks. Having to search
> for the declarations with no idea of what file it's in ridiculously slows
> down productivity. You demonstrate a problem in a program I've never seen
> before written in VB6 and I can track it down in the code in just a few
> seconds (it may take longer to actually fix the problem, but finding it is
> usually trivial.) I can't live without that anymore. I'm old and cranky.
>
> ... and that's the end of my rant.
>
> ken.
>
> Now I've got to do the homework Bernie gave me.... sheesh...
Don Cole
7. Re: Any PB & ADO gurus?
don cole wrote:
>
> ken mortenson wrote:
> > Another thing (again not the fault of Euphoria) is I wrote a windows program
> > right after my skipper submission using win32lib. When I updated to a newer
> > version of win32lib my program didn't work anymore. So I won't use win32lib
> > because I don't trust it to not break my program in the future.
>
> This could easly be fixed with
>
> include win32lib_ver3.2.exw
>
> include win32lib_ver4.exw
>
> etc...
Your making me shudder Don! That is a solution, but is it the right one?
Remember, this is Don Quixote your talking to. Making something work is
not enough. As a programmer I feel great responsibilities. Programmers
seem to know, to a greater or lesser extent, that they have a responsibility
to produce a product that satisfies the customer. Yes, they all know they
have a responsibility to make things work. But they have another
responsibility that usually doesn't get the attention it deserves. They
have a responsibility to be humble.
Your solution, in my opinion for what it's worth (IMOFWIW), deals with the
first two but fails to address the third. Let me explain why if I may.
I strongly believe in the concept of the humble programmer. I often talk
about ugly code and the two are related. Ugly code isn't just funky syntax.
It isn't just avoiding spaghetti code. Ugly code is fragile. Everything
breaks, but solid code breaks in ways that are predictable and managable.
Your solution certainly might be managable but increases the workload of
any (you can't always assume this to be yourself) that follow you. Your
solution is a sledgehammer which is fine, but for me it's not the right one.
I hope I haven't offended and I know I haven't explained myself well.
BTW, my attraction to Euphoria is partly because I see it embodies much
of the wisdom I feel my experience has given me. I also see a lost
opportunity cost. There is a reason VB is third in popularity. There is
a reason it's not number one. There is a reason Euphoria is 47th. Euphoria,
could go in either direction. With the right changes, I see that it could
go to number one and stay there with no challengers. The wrong changes will
leave it languishing below the predominate languages. I see a lot of people
advocating the wrong changes.
Nothing gives you more raw power than machine language (best written
with a macro assember of some kind.) But it's not popular. Why? No, it's
not because ML is hard. It's really not any harder than Euphoria. It's
because it's difficult to be expressive in ML. Euphoria's strength is
that it is expressive. Algorithms are easier to write than in other
languages. But it has some of the shortcomings of ML too. This is best
expresses by the INCLUDE keyword. Include makes your program one long
linear list (ignoring loops and branches for the moment) which is really
all it ever is to your machine. People are not machines. Machines do
some things better than people and people do some things better than
machines. We need to play to eaches strength.
People naturally conceptualize in a modular way rather than linear. We
divide and conquer. This is our strength.
...and that's a lot of hot air. Don, you do push my buttons! That's
probably a good thing. My best response will be by example. So I need
to get busy on my project which I hope will show you some of what I've
talked about here. I'm not doing the fun stuff yet because of some of
the show stoppers I working on, but once I'm past that I should have
code to upload within a short time after.
Again, thanks for your help. Don't let my bloviating fool you into
thinking I don't greatly appreciate your responding because I certainly do.
8. Re: Any PB & ADO gurus?
I have a habit of writing "your" when it should be "you're". Please forgive.
