Comments

# Larry Johnson said on October 12, 2007 12:56 PM:

Our product name is PREMO XPERTS and is used by the process, manufacturing, and power production industries to improve facility performance and optimize their preventive maintenance program.  It has been in continuous use at some locations for over fourteen years.  We started with MS Access version 1.0 and are currently using version 2002.

Clients discover our product via referrals, internet searches, and trade show/conferences.  

Our three biggest issues are installation, managing end-user licenses, and providing clients with updates.  I would like to see MS Access move away from the client-server model and towards browser-based.  Yes, I know there are other dev applications that will run in a browser, but too much time and effort are invested in our Access platform.  I have many other ideas and suggestions, but don’t want to make this post too long.

# Matt Carmichael said on October 12, 2007 2:51 PM:

My company has several industry specific applications that are sold trough a third party or directly to government agencies.

Distributing updates and managing licenses can be challenging.  Once the initial application is installed – having the ability to distribute updates, users can install (without administrative privileges or IT assistance), would be beneficial.  

Also would like the ability to notify users of new versions and definition updates through the custom application by communicating with a secure website.  

Having the ability to prevent the user from using the application if a critical update needs to be installed would also be a great feature.  

I have created a simple update utility that checks for updates via IE – however Vista protected mode is preventing its use. Utility located at http://www.myaccesstips.com/deploy/webupdater.htmlAV22

# Matt Carmichael said on October 12, 2007 2:56 PM:

The utility link should: http://www.myaccesstips.com/deploy/webupdater.html

# Vladimir Cvajniga said on October 12, 2007 4:04 PM:

1) Please, give us some lessons about how to safely install Access applications on machines with different version of Access. I'm sure Access team knows about their BUGGY PDW, which is not able to do anything correct and safe!!!

2) Create a professional install tool, something like Sagekey scripts for Access. I really need one. I have spend my money for Access Developer edition... well, I don't really know why you call it Developer edition if developers can't create easy and safe installation packages. :-( <VERY ANGRY> <MAD>

3) I hope we all get the new installer for free as soon as it's available. Thank you very much in advance.

4) At the moment I'm with A2002. In accordance with A97 it's a real crap - too buggy... and thus no rapdi development.

5) Throw away new A2007 developer's GUI - it's unbelievably complicated and slows down development. See Clint Covingthon's blog: http://blogs.msdn.com/clintcovington/archive/2007/06/07/do-you-like-the-new-navigation-pane.aspx

6) FIX OLD BUGS before any other new release of Access. MVPs will tell you stories...

# Vladimir Cvajniga said on October 12, 2007 4:09 PM:

7) And, yes, I need an installer in Czech language...

# Cameron Frasnelly said on October 12, 2007 6:05 PM:

I'm glad to see you are even thinking about this!  #1 Add built in professional grade controls: Treeview, Grid, etc.  With the ability to sort, change color or icon by value, etc.  

# Rickard Olsson said on October 12, 2007 6:53 PM:

I once did, but I gave it up!! My company had a very comprhensive package for HR (1999), which was filled up with great features and very competitive, when my prospects met the message from Microsoft, that Access was dead. Are you serious this time??? What happended that time was that my prospects totally lost interest. I still have the package and now I have got some interest for it the last two months - your impact on the market is so hugh that you must be very carfeul on how you act! I was burnt!!

# M. David Matney said on October 12, 2007 11:55 PM:

Yes, we have a few industry vertical market solutions we have developed that are quite successful.  Our key problem areas are also mentioned by others whereby:

A) something can work on all of our test machines (abot 20 machines total) and each test machine is setup with different configurations, yet I onstantly run into issus where installs in client enviornments have problems running the solution.  Usually a windows update will take care of it.  

B) the attachment of access to office causes significant problems with an alternate version of access is running

C) Other problems have been encountered, but Ive brought these to your attention in various previous posts.

Access has a breat potential as a RAD tool if you would start treating it as such vs. a Office Tool.  Most office users are not going to versed enough to use Access anyways, and keeping it as part of office doesn't benefit anything.  I see it does more damage.  I am constantly having users Uninstall Office Professional and selectivly install everything except access just to keep these issues from occuring without production products we send out as complete solutions.

Im tired of having to explain to customers WHY they have problems with our software running with microsoft office 2003, but no one elses softwaer has problems.  And its always related to having access 2003 loaded alongside access 2007 - This should not be part of microsoft office.  Its not an office productivity tool, rather it is an RAD tool used by developers, not end users.

# Brandon Smith-Daigle said on October 13, 2007 10:57 AM:

My company offers a Microsoft Access product ("UI Builder for Microsoft Access") that serves as an application framework to help Access developers jump-start their development process by minimizing the need to create common Access functionality like attractive menus, event logging and alerts, Mail Merge, and more.  Our Enterprise Edition includes user-level main menus (similar to a Switchboard that is customizable by user).

We've built in over 25 different menu commands so that Access users can configure a menu button to do nearly anything they would want, without requiring any VBA experience on their end.

People use our application because they want more attractive Switchboard-like menus with more functionality, and they don't have the time or knowledge to build it themselves.

In terms of what would help me sell more product, Microsoft's continued support for Microsoft Access, and a solid roadmap for VBA or it's equivalent.

Finally, customers purchase the product online (via Office Marketplace or directly through our site).

Thanks for asking!

http://www.opengatesw.com/products.aspx

# Gilad said on October 13, 2007 12:05 PM:

Thank you for this topic!

I read a few sites that try to compare between desktop and Web applications to see which is better. Although you can always say that it depends on the purpose of the application, in general the conclusions were that a desktop WEB ENABLED desktop application will be better because the improved user interface and speed of accessing the data. So how can we “Web Enable” a desktop application? I think deployment of the application and its updates is a critical key issue. The greatest advantage of a Web application is that you don’t need to deploy anything since all that is needed from the user is a browser. If this advantage could be bridged even some, then Access can still rule. I think the Access team should brainstorm in order to find ways to make this process easier for developers and users.

I agree with Larry above that the key issues are installation, managing end-user licenses, and alerting and then providing clients with updates, but I do not agree with him on moving away from the client-server model and towards browser-based. That will take away the edge access has over other available platforms, that being the quick and sophisticated user interface.

I currently have four applications that I would like to deploy over the internet.

Here is what these applications do:

1) Manage academic journal’s editorial process.

2) Manage the administration of the Dean’s office of academic faculties

3) Manage the administration of Orchestras and Choirs

4) Help people learn new languages.

Thanks

Gilad

# Vladimir Cvajniga said on October 13, 2007 12:18 PM:

1) Distributed database for "crossworders" with ~400.000 records & supprt application (filtering, creating various search criteria, ...)

2) Advertising.

3) Desperatelly need a professional installer in Czech language. Your PDW is buggy and I'm experiencing cross-version incompatibility issues. <MAD>

# Vladimir Cvajniga said on October 13, 2007 12:25 PM:

1) Right now I'm working on a HUGE accounting system.

2) We shall advertise...

3) In this case I REALLY need a professional installer in Czech language. Your PDW is buggy (see above) and I'm experiencing Access cross-version incompatibility issues. <MAD> We have just released a "half-way-demo" for our businness managers and we're experiencing BIG INSTALLATION PROBLEMS!!! <VERY ANGRY>

Also, I'd appreciate that you break (funny) 2GB mit for Access database... 100GB should be OK in this modern era... an especially for this project! Thank you very much in advance.

# Vladimir Cvajniga said on October 13, 2007 12:26 PM:

As to 3), pls, go to my post at http://blogs.msdn.com/access/archive/2007/10/11/a-chance-to-influence-the-direction-of-access.aspx#comments.

# SentinelUk said on October 13, 2007 12:49 PM:

1,  we develop - install CMMS (Computer Maintenance Management Systems) to the manufacturing industry.

2, Website, Brochure and word of mouth.

3,  A much more robust version of .mde to assists with copy protection. I.e. not only stopping tables being viewed in design but also queries, reports etc.

A Conversion wizard. MS Access to .NET visual studio would be like gold for us.

# Peter Marsh said on October 14, 2007 8:04 AM:

What is the application scenario and why people use your application(s)?

My app provides a workspace to operate a custom manufacturing facility (specifically joinery, but not limited to). 10 years in live development for my own business. (www.isminteriors.com.au) Running A2003 .mde in runtime environment. workgroup security active.

How do customers/clients find your application(s) to purchase?

The product is in early stages of marketing for sale. It is expected that specialist sales, installation and support will be required. Expect to ship with A2007 runtime once Office 2007 SP1 is released to fix shortcut menu bug with 2003 .mde. workgroup security is critical to the app design. database will not upgrade to 2007 format

What features could we add to Access that would help you be more successful?

A. ability to make minor formating changes to customers reports in .mde format would help in customers feel different to others using the program. (distributing .mdb is out of the question)

B. I am disapointed workgroup security has been discontinued. can't it just be left alone as part of the new format ?

C. My application is too complex (Cannot open any more databases problem) for a split db. We have developed a custom method for importing client data into new .mde. eliminating the need for split database. updating the file is simple, just perform an import of data to a new .mde .  Generally I have not seen this option anywhere else.  Is it possible can be built in as a standard option ?

D. We have developed security (specifically licencing) by issueing a licence key tied to relevant information within the clients database (including renew date). It is IMPOSSIBLE to run the application without the correct key. Workgroup security was never going to cut it here. Maybe you could offer a similar method of securing db as standard

E. Some how you need to build in the option to disable the importing of tables and queries (from salable db) into another db. This is a major problem in protecting IP

F. Access as a platform is criticised by competitors (and doubt is planted in customers minds, not all customers are well informed). Example XYZ product uses (ANY SQL Backend).  Its really great because you can have thousands of users.  Fact is none of their clients will use the product in an environment with more than 10 users and for each user you must pay for a new licence. Access (shared .mde)  can handle 10 users with no licencing issues. I think you need to promote the use of access as a serious small workgroup application environment.

Hope this helps

Contact information (via the email option).

peter@icondst.com.au

# Kevin Bell said on October 14, 2007 2:25 PM:

Our product is not a traditional vertical application, but rather a suite of development tools specifically designed to help Access developers create better Access applications faster.   AccessUI (www.accessui.com) provides a consistent, professional application framework that offers an advanced user interface that includes data navigation and application security.

The AccessUI has been used for years internally but we have just started marketing to other developers.  We earned 2007 Launch Partner status in the Microsoft Office System Solutions directory, but that seems to be generating minimal inquires.  Early indications are online marketing will be the most successful as we are market to a very small percentage of the Access user base.  Our biggest challenge will be educating developers on how powerful the AccessUI is.

I think the biggest feature Microsoft can add in the next version of Access isn’t some new bell or whistle, it is a whole new identity.  Microsoft needs to promote Access.New as a RAD tool, not targeted as an end user product in the Office suite.  FileMaker heavily promotes a developer conference every year.  Is FileMaker really a better development platform than Access?  It sure seems to be marketed to developers better.

<SoapBox>The best thing Microsoft did was bundle Access with Office as it put Access into the hands of millions and millions of users.  The worst thing Microsoft ever did was bundle Access with Office, as it put it in the hands of millions and millions of user that don’t know the first thing about relation database design.  As a result people end up creating applications that don’t work or perform like they think it should, and often Access gets the blame.  Access is an extremely powerful tool and in the hands of an experienced developer, or a user who is willing to spend the hours necessary to conquer the learning curve, can create applications that rival any other programming language.  Unfortunately Access is often dismissed as a toy by IT departments, yet in 3 month I can do what would take them a year or more. </SoapBox>

I would see Access.New marketed as a front end tool that would work seamlessly with prior Jet databases and have very tight integration with SQL Server.  It should have a free viewer/runtime that would be as simple to install as the Word or Excel viewers.  As you can see from the other posts, deploying an Access application can be a painful process.  If you can simplify the deployment you will get more people creating niche applications which will only help promote Access.

How about ClickOnce for Access? :-)

# Michael Hnatt said on October 14, 2007 7:48 PM:

Per your request for Access application sellers:

1) Our product name is ShoWorks - which is the transaction processing system for just about all of the county, state and national fairs across the nation (for example, if you participate in your own State Fair or county fair, the chances are ShoWorks processes your information).  This product originated using Access 2.0 in 1995 and has since grown into the primary system, now running several million $ in transactions, soley from an Access platform.  http://www.fairsoftware.com

2) Originally marketed via direct mail, trade shows.  Now in addition, word-of-mouth, web search, magazines.

3) If we had just one wish, it would be to implement "Linked" reports (similar to linking tables).  But we do have a nice workaround that we are going to release (to allow for reports to be created/edited even in an .mde  http://www.gladstonesolutions.com)

4) Michael Hnatt - president

# Steve Palm said on October 15, 2007 12:22 AM:

We sell an application called Image Accounting which is a full featured accounting system written in Access.  We have been working in Access since version 1.0 and have sold Image Accounting to thousands of customers since 1993.  We primarily market via the Internet, magazines, resellers and word of mouth.

Access is the best RAD program I have ever used.  The only real limitation in Access for us is the number of users that can connect to it over a network (and now the Internet).  Most everything else we have been able to work-around pushing Access to the extreme with over 350 linked tables (Access or SQL Server), 1450 queries, 550 forms, 350 reports, 100 modules and several VB6 Add-Ons.

If Access was not part of Office and could be compiled as an EXE it might be taken more seriously by the developer community.  I think since its part of Office, most people discount the power of Access or use it to simply store some data in tables which you can do in Excel.  We spend most of our time writing VBA code in Access which I bet only a small percentage of Office users even know how to do.  

Access has one of the best report designers on the market.  I have created hundreds of reports in Access and to this day I have never had a problem creating even the most complex report in Access.  A lot of this is because Access exposes the entire VBA language to the report designer.

That being said, I have two problems with the Access report designer.  There is no way to save a report as a byte-array (external text file) and there is no end user report designer included with the Access Runtime.  One of the most important things to our users is the ability to customize reports.  If there was a way to save reports as a byte-array (text file) then it would allow us to save custom reports easily to a table or as an external file when doing customization work for customers.  A user could also copy one of our original reports and customize it and save it directly into a table instead of the application MDB/MDE.

The advantage of this is if we deploy a new version of our application it will not overwrite their custom reports since it's stored along with their company data in a separate database.  Another benefit is that if a customer hires us to customize a report for them, we could deploy it as an external file that they could import into a table or even run on the fly.  This would make customizing an MDE possible and very exciting.

To elaborate on my above comment of being able to work-around limitations in Access, we wrote an external report writer and designer in VB6 using ActiveReports from Data Dyamics.  This allows our customers to save a report they design to a linked table and share it instantly over the network will all the other users.  You can also export that report to almost any format including PDF and even email that report as a PDF on the fly.  Even though this solution works well it is not as easy to create or edit reports as it is in Access.  It also requires us to recreate all our Access reports in another reporting tool which is a lot of work.  Now with Access 2007, the report writer has been pushed to new levels making it better than ever.

Deploying any application takes a lot of work and testing.  We have spent a few hundred hours creating and bullet-proofing our installation routine so it would be great if it was easier.  There are so many things that you must consider and test against no matter what application you deploy that I am not sure it will ever get better.  I would highly recommend to all serious Access developers that they purchase a professional installation program and look at sagekey.com for scripts to help you deploy the Access Runtime along with your application.

# polythene said on October 15, 2007 1:51 AM:

it'll be usefull to know about all applications you have gathered here. i mean, provide a post with all selling applications you would receive...

# Robert Stewart said on October 15, 2007 9:51 AM:

I have a very niche market. I do agency management software for social service agencies. All my sales are word of mouth. I use MS Access 2002 - 2007. I will only use SQL Server as the backend DB because of the problems with db corruption of the data.

Get rid of the damn ribbon. It is garbage and should NEVER have been done.

Running 2003 mdbs inside of 2007 corrupts them every time.

# Rebecca MacMullin said on October 15, 2007 9:51 AM:

I'm also with Comtech Solutions, and I know Steve has filled you in on some of the technical information about Image Accounting, but I thought I'd add a link to the demo if you would like to download and look at the application: http://www.comtechsolutions.com/csdemos/iapremier10_demo.exe

# Mark Jones said on October 15, 2007 10:07 AM:

Our product (Troika) includes wealth management accounting, company administration, time and billing and investment management modules.

We sell through the online presence and through developing our own sales database - it's a pretty niche market.

We do have ASP and VB6 elements (hopefully .NET soon) but we have so much functionality in Access because it is such a fantastic RAD tool. Our clients really appreciate it when we deliver new functionality in a short timescale. The interaction between the database engine and VBA makes the production of very complex routines faster than any other language. This also makes the reporting a lot more powerful - an area that appears to be an afterthought for most programmimg languages.

So improvements? Deployment could be easier, but making the client thinner would help a lot. I don't mean the Access program; if you have a 100 forms and/or reports in an mdb that mdb becomes large - >30MB. And when it's opened it 'bloats'. This is quite a headache for people who want to deploy on Citrix or Terminal Server (which generally works very well) because they have to spec the server with loads of hd space and, more importantly, loads of RAM. This 'bloating' has been around in all versions I've used (now on 2007) and I really don't know why it's so bad.

Functionally, Access is really great, but perhaps continuing the recent improvements to the reports would be good - more 'drilldown' ability and so on. It would be really nice to be able to design an interface that is more cutting edge too (WPF?), but I wouldn't want that introduced at the expense of the ease of the current interface. Likewise for introducing a VB.NET replacement for Access VBA.

Thanks for this topic; I know many developers who use Access professionally and we are often frustrated at the apparent 'downgrading' of Access as just an end-user tool; in fact, it's a fantastic product for professional application development.

# Mark Jones said on October 15, 2007 10:16 AM:

I forgot to add, Access is really only used by us as a program, *not* as a database. Our data persists in SQL Server. However, the ability to also use the local database for temporary work is very handy, and adds to the power of Access. Anything that can be done to improve links between Access and SQL Server is welcome, although it generally works very well, and has done for some time (don't break it!).

# Charie Zhu said on October 15, 2007 10:33 AM:

Our company once run business on Access heavily. I moved the data end to SQL Server and left Access being a rapid GUI design tool as front end at 2004. I believe that saved the team, even the company.

Now, everyone in the team wants shift to ASP.NET as client services but me. Truly, programming in Access is far away from modern software technique.

# Mark Jones said on October 15, 2007 12:08 PM:

(For Tom Wickerath)

Thanks for the info Tom. I'm aware that temporary tables cause bloat, (and I guess one should expect it!); but in my experience this 'bloat' is reclaimed when the records are deleted.

But general development tasks also cause bloat which doesn't seem to be reclaimed when objects are deleted. After some years of use one is left with quite a file! And, infuriatingly, exporting all objects to a fresh mdb doesn't seem to create a smaller file (although I think it used to in A97); and, of course, each new version adds a bit to the last file size.

We've been through the list of what causes bloat and think we've addressed them all; we discovered the close recordset one some years back, so that shouldn't be an issue.

Thanks again for the suggestions...

# Tom Wickerath said on October 15, 2007 12:18 PM:

(For Mark Jones)

Have you tried decompiling your VBA code, following this up with a compact and repair?

Note that if you are developing with Access 2002 or 2003, and you are using the 2002-2003 file format, that you can expect development bloat that is not recovered by compacting. It should, however, be recovered by importing all objects into a new container:

   Database bloat is not stopped by compacting

   database with Access 2002 format

   http://support.microsoft.com/?id=810415

# Brent Spaulding (datAdrenaline) said on October 15, 2007 3:37 PM:

(For Mark Jones)

>> but in my experience this 'bloat' is reclaimed when the records are deleted. <<

An Access database will never get smaller on its own, you MUST compact it to "reclaim" HD space.  Deleting records doesn't do it alone ... that is why many developers will actually create a temp Database file that is for temp tables, that way the temp tables are not part of the application file and thus won't cause application bloat.

# Steve Palm said on October 15, 2007 4:37 PM:

(For Mark Jones)

The best trick for keeping your Access MDB small and running extremely well and corruption free is to decompile it frequently and then compact it.  I have had great luck coding in this decompiled state instead of writing code when the MDB is fully compiled.  This greatly reduces if not eliminates corruption.  Here are the steps you need to take to decompile your MDB.

From the Start menu select Run and paste the following.  Note: you might need to change the path to point to where you installed Office.

"C:\Program Files\Microsoft Office 2002\Office10\msaccess.exe" /decompile

Then, in the Run box click the OK button which should open Access.  Then from the File menu select and open your MDB and during this time make sure you press and hold the SHIFT key down to prevent your MDB from opening any forms or running any code.  Once you are at the Database window immediately compact the MDB.

After you do this, your MDB will be the smallest it can possibly be and will also be in a decompiled state.  If you have trouble with your MDB corrupting often I would highly recommend using the above steps frequently (weekly).

As a side note, when I install different versions of Office/Access I always install them to a different folder instead of the default “Microsoft Office” folder.  For example, I install Office 2002 in the “C:\Program Files\Microsoft Office 2002” folder and Office 2003 in the “C:\Program Files\Microsoft Office 2003” folder and Office 2007 in the “C:\Program Files\Microsoft Office 2007” folder.  This seems to be the best method of installing Access so it does not conflict with other versions of Access.  I currently have Access 97, 2000, 2002, 2003 and 2007 all installed on my computer with no problems at all.

# Vladimír Cvajniga said on October 16, 2007 3:00 AM:

Steve Palm (different versions of Office/Access): There's a problem if end user runs a PDW install package on his/her machine with different version(s) of Access/Office.

# Mark Jones said on October 16, 2007 4:38 AM:

(for Brent Spaulding)

Thanks, I'm aware that it's the compacting that reclaims the space after records are deleted, and I'm familiar with the technique of a separate temp tables database. My problem isn't bloat caused by temp tables but bloat caused by development. I obviously didn't make that clear enough in my original post!

(for Steve Palm)

Thanks for the suggestions. Despite fairly large mdbs we have very few problems with corrupted mdbs; I can't remember the last time we had such a problem whilst developing. It rarely occurs in the production environment either.

Oddly enough I have tried the decompile solution in the past on a few occasions, having seen it suggested for this problem, but it has tended to corrupt the mdbs! I've not tried since moving to  2007, though, so I'll give it another try.

# KiwiBruce said on October 18, 2007 4:08 PM:

We develope 2 products used in dental practices + we have built some 50 + custom applications for clients. Some of those with 40+ users on a site (Access/SQL Server). Most of it is word of mouth and referrals.

First off, thank you for asking. I finally have some hope of this sign of MS realizing there is a huge development community out there that need some support and recognition from MS.

I concur with all of the above items, My number one issue is Runtime Install It MUST be smaller in Access XP the PWD builds a 100 meg package! Why on earth does it include IE 5 still?? I see that A2007 still is some 50 meg Crazy  there has to be a better way. Also I use a 3rd party Install to make things better but not being able to modify the MSI is a pain in the butt. I want the Runtime to install in another folder, not the default.  I am not happy about the Share point direction as My clients are small and have no interest in installing a simple server half the time let alone share point. Some one else said One click Update function , Yes please!. More and better native controls Like a Treeview wizard and the like. I am holding off migrating my apps to 2007 untill SP 1 comes out as I have run into too many weird issues where perfectly good code simply fails in 2007 but same code works on 97, 200, XP and 2003.

Well I am done for now, Thanks for asking and I would love to be involved in any process you may start with enhancing Access for developers.

Count Me In!!

Bruce

# KiwiBruce said on October 18, 2007 7:19 PM:

Oh also, can someone PLEASE..... Update MSGraph ! It is stuck in the 80s.  Why has this module been forgotten by the Office team! In Access 2007 you have this new slick updated interface and then it you want to put a graph on a form and it looks really horrible! I would like to know which 'team' owns MSGraph...or is the problem no one owns it and that is why it hasn't been updated in over 10 years?  Please don't bring up PivotChart. It is great for power users and adhoc data mining it is usless for applications, I have tried this and spend way too much time trying to program it NOT to do things and to try and nail it down.

# Vladimir Cvajniga said on October 18, 2007 7:27 PM:

Unfortunatelly, "A chance to influence the direction of Access" at http://blogs.msdn.com/access/archive/2007/10/11/a-chance-to-influence-the-direction-of-access.aspx has been closed after a very short period. IMHO, there was not enough time to open public discussion about programmers' needs. So that our chance to influence the direction of Access is not too big... <cry>

# Vladimir Cvajniga said on October 18, 2007 8:01 PM:

3) What features could we add to Access that would help you be more successful?

Reports: multiple output for detail and groups based on conditions.

In PC FAND (DOS relational DB system) we had something like this (#DE stands

for Detail, #CF for Control Footing):

#DE (myNumber<100) Field1, Field2, Field3;

______    ______    ___________

#DE (myNumber>=100 & myNumber <200) Field4, Field5;

                ____________.__   ____________.__

#DE (myNumber>=200 & myNumber <300) Field6, Field7;

_________   ___

#CF_Town (Town="Praha") Town,sum(Field4);

__________  ____________.__

#CF_Town (Town="London") Town,sum(Field5),Field10,

Field11,Field12,Field13,Field14;

__________                             ____________.__  ___

Field11: __________                 Field12:  ____________

Field13: __________                 Field14:  ____________

etc.

# clintc said on October 19, 2007 1:02 AM:

Thanks for everyone that has sent mail. This has been great for me to see what people are doing with the product. I have been sending around lots of links to the development team encouraging people to check out different apps.

Vladimir--threads don't get closed because we aren't open for feedback. threads are automatically locked after 7 days because of the amount of porn spam that accumulates if we don't.

Once again, thanks for all the replies and cool links.

New Comments to this post are disabled