Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

1115 Invalid operation for the cursor. 3

Status
Not open for further replies.

Steve Yu

Programmer
Nov 6, 2021
88
US
Hello,

Need help.
Got this error trying to run any Alter Table command (alter column for example) against the cursor which was created via SPT SqlExec().
But ONLY when the cursor was empty.
If I inserted several records first, then the same Alter Table command would work.
Very odd.

Steve Yu in Houston
 
I did never say anything about modernizing the interface, just have a clean database defined. For the benefit to have data in a natural datatype to be able to use the T-SQL functoins meant for it. Why is this discussion going off topic?

Chriss
 
Chris,

I totally agree with you on the benefits of maintaining a consistent and clean data structure throughout.
It is just that we have so many fires to put out, we have to leave building sound data structure for future improvement.
Also I understand this is a tech forum, but our VFP/dBase to SQL conversion is a very interesting case study worthy of "code-dissection" discussions.
Our approach was not conventional to say the least.
As a matter of fact, the first question the guru developer who helped us with the conversion project asked while we were doing our feasibility study was: "who is going to maintain this system after all said and done ?"
I'm not yet able to answer that question. And VFP talents are harder to find by the day, especially locally.
Underneath the archaic 80x25 display and dBase III/FoxBase era coding (that had been brought up to VFP 9.0) we now have a solid SQL backend, the objective of our project.
The functionalities we have brought into this system over the years are phenomenal for what it can do.
In addition to the mundane tasks of providing tools of inventory control, sales and accounting for 100+ people in multiple cities, the system also handles real time integrations with online retail giants, banks, and other entities that offer API.
Basically that's the reason for us not going away from it.
Again really appreciated the help and attention I've been receiving since I discovered this forum.
Best regards,

Steve Yu




 
Tamar,

Similar situation except I'm still here.
In my case it is very satisfying to have the owner's trust ("what happens if you got hit by a truck tomorrow" was the most frequently asked question when I was auditioning for major projects back in the days; and it is a legitimate question) and to have been able to help the company grow from a mom and pop outfit over the years to a dominating player in their industry today. I'm certain and they know the VFP system has played a big part in all of this.

Steve Yu
 
Steve: Of course, that "what if you get hit by a truck (or a bus or ...)" is absolutely a fair question for someone relying on a solo programmer writing custom code. I hope you have good documentation for your system, and that you have a contract with these folks that makes clear what their rights are if you're not there. (In the case I mentioned, I had the owner of the company sign a waiver to protect me if someone came along and asserted rights to the code.)

The downside of still operating in a FoxPro 1 mode is that if you're not there, it'll be even harder to find someone to come in and help out than if it were a fully VFP app. Those of us who ever worked in pre-VFP FoxPro are getting up there.

My husband is a solo practitioner lawyer and a few years ago, after attending a relevant continuing ed course, he spent a whole lot of time doing succession planning. He has an arrangement with a small firm that's willing to take on his clients (if they're so inclined) if he's either temporarily or permanently unable to continue to work. He also has written documentation about all of this.

I know I should do something similar, but I haven't gotten there. OTOH, I have connections to a lot of others in the VFP community and my husband (and, to some extent, my adult kids) know who those people are, so would have some idea who to talk to if something happened to me. (Happens that, at the moment, my principal client is another developer, which helps, too.)

Tamar
 
Tamar,

There is more to my story.
Not sure if I should discuss it here as this is a tech forum, but I'm gonna try anyway as I want to share my experience with other VFP diehards (you wouldn't be here if you don't believe VFP is still a viable database solution, would you ?)
To answer your questions:
1. rights to customized code: no issue, I always consider they belong to my client; I get paid by time spent.
2. documentation: the original package had been very well designed with full documentation (separate user and developer reference manuals). I started out with installation, training, and user support as it was already a fully-functioning system. As the time goes by features and customizations get added, thanks to the included source code. As such, the coding are easy to follow if you know dBase (and that's a big assumption nowadays)
3. succession plan: it's not easy. we scouted nation-wide for my successor for quite a while (client chose to stick with this 'live dinosaur' instead of starting over with newer technology for reasons I've enumerated previously). Luckily we found and have trained a couple of local .NET people who knows nothing about VFP (blame Microsoft for that) but with good coding experience and were willing to take the job (inhouse full time unlike me).

Tamar said:
it'll be even harder to find someone to come in and help out than if it were a fully VFP app.

It's going to be very hard either way. Very difficult to find VFP talents.

Regards,

Steve Yu
 
On the IP rights issue, in the US, by default, if code is written by an independent contractor, the rights belong to the contractor, unless there's a contract otherwise. So you should put something in writing, in case someone comes along later who isn't part of the discussions you've been having now.

FWIW, code written by an employee is presumed to belong to the company, unless documented otherwise, which makes sense.

Oh, and I probably should add that I am NOT a lawyer and I'm not giving legal advice. (I'm married to a lawyer, so literally have in-house counsel. ;-) )

Tamar
 
Tamar,

You do sound like an attorney too [smile2]
Well noted and will keep your advice in mind.
Years ago one client of mine did ask me sheepishly about the rights to the coding (a major VFP project I wrote from scratch that handled real-time POS transactions in 100+ retail stores) that they were trying to replicate for franchising considerations. That business plan did not pan out but now I know they must have consulted their attorneys about the IP rights as there were no agreement oral or written with me. I assured them they can have it because I had been paid for time spent and the ongoing support revenue. That was OK by me.

Steve Yu
 
I note Tamar's point that, in the US, the default is for the IP rights to belong to the contractor. But I sometimes find that clients need to be reassured that they won't be over-dependent on me for maintenance and enhancements. So, rightly or wrongly, and for what it's worth, the following is some typical wording that I use when setting out my terms for custom programming:

All software that I develop for you as part of the project would be your copyright which you would be free to exploit in any way you wish. In particular, you would own the rights to the source code.

As an exception to the above point, I would wish to retain the copyright in any of my own general-purpose routines or components that I incorporate into the system, and in any general-purpose programming tools that I develop or use as part of the project. All such items will be clearly marked with my company’s copyright notice.

The aim of the second paragraph is to allow me to re-use in other projects any classes or functions that I create for this project (which is, after all, one of the main reasons to use OOP).

I'm not saying this approach is right for everyone. But if anyone here wishes to use similar language, feel free to copy the above wording. (I won't sue you.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Mike,

Mike said:
I'm not saying this approach is right for everyone. But if anyone here wishes to use similar language, feel free to copy the above wording. (I won't sue you.)

Very funny.
Excellent point.

Steve Yu
 
I've taken a different approach:

TSLLC retains all copyright and patent rights to all materials developed by it under this agreement, and grants to CLIENT a permanent, non-exclusive license to use and employ such materials within its business at no additional cost. TSLLC retains the right to use these materials in its business in any way that does not conflict with the non-disclosure clause of this agreement, including but not limited to reuse of code for other clients and writing about the code or the process for publication.

That way, I don't have to think about what code belongs to what client.

Tamar
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top