Paul,
What I would like to see is an intigration of the SQLite/SQLitening to make FF4 a 4GL database generation tool. Something like Clarion.
Quote
Clarion is a software development tool to help you get your business applications completed up to 10 times faster. Clarion features a Template driven Code Generator that automates the creation of complete Database Applications. Clarion features roundtrip Code Generation, which means that it preserves all of your hand-written code while still allowing you to make changes and re-generate your application, or any part of your application, as often as needed.
At the core of the Clarion IDE is the Data Dictionary -- a metadata repository which stores Table definitions, business rules, attributes for defaults on how columns should be displayed on Windows and Reports, and user defined options.
Website: http://www.softvelocity.com/
Quote
Clarion is a commercial, 4GL, object-oriented, programming language and Integrated Development Environment from SoftVelocity used to program database applications. It is compatible with ISAM, SQL and ADO data access methods, reads and writes several flat file desktop database formats including ASCII, CSV, DOS (Binary), FoxPro, Clipper, dBase, or all SQL RDBMS databases via ODBC, MS SQL Server, Sybase SQL_Anywhere and Oracle through the use of accelerated native database drivers, and XML, Clarion can be used to output to HTML, XML, plaintext, and PDF, among others.
One of the Clarion Development Environment's primary features is its use of "templates" which are used in conjunction with a code generator (named AppGen) to produce much of the repetitive, time consuming code that is typically required when producing an application. An "embeditor" shows the developer the code that will be generated and embed points where the developer can enter their own hand-code in the context of the template generated code. Advanced Clarion programmers can create their own templates, or edit the existing ones.
Overview: http://www.softvelocity.com/Clarion/Clarion.htm
Is this type of idea beyond the scope of what you envision FireFly becoming? I hope not. I hope you give the idea some thought and concideration.
I also was hoping that FF3 would have integrated support for SQLitening ... only to find out that the ADO stuff in FF2 had actually been removed.
Oh well, it is early in FF3s life...
I guess that you could say that ADO in FF2 was an early attempt at some type (albeit, limited) attempt at database integration. It was removed because the includes that shipped with FF2 were from Jose Roca's collection and ADO has totally changed in Jose's new PB9/COM based collection. FF3 does not support the old style (pre-PB/COM) method of COM so it only made sense to take it out. COM/ActiveX in FF3 is different than FF2 - that's why PB9 is required for that functionality.
Database support for FF3 is a tricky subject. I get a few requests for it every so often. The problem is what databases to support and how. There are so many different kinds of databases and as soon as I add one then you can be sure that another will be requested. It could become a support nightmare?
Currently, the best way to added database support is to #INCLUDE the files into your project via the FF_AppStart special message handler. All I do is copy the SQLitening.inc file to the "\modules" folder of my project and then include this line in the FF_AppStart:
#INCLUDE "..\modules\sqlitening.inc"
Pretty simple and works perfectly.
On a broader scale, customers have asked for databound controls and the like. Not sure how I feel about that yet.
Nonetheless, I imagine that an SQLitening/FF3 tutorial could certainly happen. I love SQLitening so therefore it gets to the head of the line. ;)
Quote from: TechSupport on November 05, 2009, 10:10:48 AM
Nonetheless, I imagine that an SQLitening/FF3 tutorial could certainly happen.
That would be a good start
Quote from: TechSupport on November 05, 2009, 10:10:48 AM
I love SQLitening so therefore it gets to the head of the line. ;)
This is why I was surprised there was no builtin support for it
Quote from: David Martin on November 05, 2009, 10:46:51 AM
This is why I was surprised there was no builtin support for it
David, what a builtin support for SQLitening could bring to FF3 ? currently we are free to choose the DBS of our choice; we can use:
- SQLite
or
- SQLItening
or
- another DBS
What could be the benefits of a builtin support ?
Jean-Pierre
Why would FF need to interface with a particular DBMS? Why not just provide a SQL language "interface layer"? (Several such PB 3rd-party SQL toolsets already exist.) The developer would use any DB engine, provided it understands SQL.
This way, all FF controls could be SQL-ready, and the SQL capability could be enabled after a legitimate SQL engine was connected.
Does this make sense from a technical perspective?
But then, Paul, rather than build and maintain it yourself, this could mean that you just enter into an "alliance" with the maker of such a toolset. Hmm, that would have its own unique set of business advantages/disadvantages...
Anyway, just trying to see what's possible...
Quote from: Jean-pierre Leroy on November 05, 2009, 11:51:08 AM
Quote from: David Martin on November 05, 2009, 10:46:51 AM
This is why I was surprised there was no builtin support for it
David, what a builtin support for SQLitening could bring to FF3 ? currently we are free to choose the DBS of our choice; we can use:
- SQLite
or
- SQLItening
or
- another DBS
What could be the benefits of a builtin support ?
Jean-Pierre
Jean-Pierre,
The advantage would be if this FF/SQL program was a database design engine, wherein, it would use a Data Dictionary that would allow the programmer to "define" the database and the FF/SQL would generate the code to build, access, search, browse the database. The advantage would be that FF/SQL would be database code generation program.
Programming languages such as "Clarion" a 4GL provides a method for fast generation of database from simple to very complex. Advantage to Paul would be that these type of programming languages command a high price. Clarion-Pro sells for over $2500.00
If I can put my 5 cents worth to give some people an example or visualize
having a DBS included in FF3 (I am only saying this to get people excited so
they nag Paul to add this ability :-).
Forget about what Database to support, you are allready using SQLItening
so you don't have to reinvent the wheel, no need to think whats the best.
As Martin said have a Data Dictionary similar to Clarion where you define the
Fields for each Record, specifiy what Key you want whether its a Unique or Non-Unique
or how many keys and then give it File name amd it's done - Presto here is your database.
As you are designing a Form you can have a option to select which Database you
want to access so FF3 can include the nessasary includes, then specify which key you want
to search or view by and you can also have an entry box to Incremental Search or Locate a record.
As for Functions you only need a handfull of High level Commands like Update,Delete and Add a record.
No need to know SQL just keep it simple, if want you can have some other Functions say
if you want to create a Database and want to fill it with data quick you can
have a Stream option (without doing a Flush after each write to speed it up).
For the Advanced Programmers they can use any of the other SQLItening functions
or custom do what they want or even choose any other DBS if they wish but imagine how
easy it would be say to add a Database for Customer records, Inventry, Animals, Electronic
parts you name you can add it so easily without any Database knowledge. This opens up
another area where you don't think twice. I was ex Clarion DOS user for many years
Database stuff is another world, there are jobs which you would never attempt before
and this is added it would be a breeze... imagine a Non Bloated Database Program.
Peter Maroudas
It is really no big thing to extend FF3 with the Database funtionality. As FireFly user you are of course familiar with the F8 functionality - the Function Library. It is no Problem to extend FF3's Function Library with your own functions. You could do this in the MySnippets folder or create an new folder for your database functions.
I have just tried to add a few SQLitening functions to the FF3 function library:
slConnect
slOpen
slBuildInsertOrUpdate
slExe
slSel
slGetRow
slFn
I created a folder SQLitening for these functions. You find this folder attached as zip to this post. To use these functions just go to the following folder:
<Program Files>\FireFly Visual Designer\CodeStore\PowerBASIC
Unzip the SQLitening folder into that folder. Start FF3 and try F8. You will see the new SQLitening functions. All you need to do now is to include SQLitening.inc into you project, put it into the Modules folder, and copy the needed SQLitening Dll's into your Release folder. See also Paul's post at the SQLitening Forum: http://www.sqlitening.com/support/index.php?topic=3134.0 (http://www.sqlitening.com/support/index.php?topic=3134.0)
I will add the complete SQLitening functions set to the folder during the next couple of days for my personal use. If anyone is interested let me know. Then I will post the finished folder here.
That is of course unless Paul has a better idea!
Rolf
2009-11-08:
Complete functions set can be downloaded here:
http://www.planetsquires.com/protect/forum/index.php?topic=1998.0
Rolf
I am new to FF3 and have not played much with FF2 or with SDK, I will attempt to have a play and learn more of its capabilities and your example.
Peter Maroudas
I agree with Rolf. FF3 seems to me be to be all about user definability and expandability. I think it might take a little time (at least for me) to fully grasp the possibilities of the CodeStore approach.
You can even create your own FF functions - or hundreds of them. Feel like wringing every last drop from the Widows API? Get after it. I suspect that CodeStore code posting/sharing is going to become a big deal around here.
One use for CodeStore that appealed to me (see Pauls post in Bugs and Workarounds concerning "Shared Code Modules work differently..." is to create an ActiveX folder in CodeStore. Then create a bunch of separate entries consisting of nothing but "#INCLUDE ONCE ..." statements that point to the TypeLib Browser include files you created previously. Expand these into the AppStart code and your done. Well, maybe not done, but at least organized.
Something I would like to see in FF3 is a method to copy any user referenced files to the Release folder automatically. This should include any filetype: .txt, .dll, etc. This would allow, for example, to have the latest SQLitening in one place and not have to remember to copy all the dll's to the release folder. Of course you would have to remeber to make a refernce to these files somewhere, somehow.
Pat
Quote from: Pat Dooley on November 06, 2009, 08:51:12 AM
Something I would like to see in FF3 is a method to copy any user referenced files to the Release folder automatically. This should include any filetype: .txt, .dll, etc.
The first thing that popped into my head when I read this statement was,
"hmmm... I bet that 'User Tools' could accomplish something like this". Create a User Tool on pre-compile that copies the required files from a target folder to your release folder.
Mark Strickland made a comment about this topic but it looks like he accidently posted it to the wrong thread:
http://www.planetsquires.com/protect/forum/index.php?topic=1969.msg16105#msg16105
I uploaded the complete SQLitening Function Library set. You can download it here:
http://www.planetsquires.com/protect/forum/index.php?topic=1998.msg16166#msg16166
Rolf
I wish there was something that bridged the gap and didn't have 4GB limitations and other issues making MS SQL still on top for large apps. When looking for a replacement I found Vista DB, but it still is hooked in with .NET and no PB version. A DB with all of its features and abilities would be perfect and replace 90% of the uses for SQL engines out there.